Implement namespacing (issue #2)

Created by: thomastuts

I've implemented namespacing since I needed it for my current project, and because there was an issue for it already anyway (see #2 (closed)). I've added a couple of tests that all pass. It supports the following functionality:

• Adding a namespace
• Adding an optional namespace delimiter (defaults to .)
• Specifying either a custom namespace or no namespace on a per-method basis (i.e. get(), set() and remove()). If the namespace is null, it will not use any namespace to get/set/remove that value (similar to the current implementation). If the namespace is given and not null, it will use that namespace to perform the operation. I'm not sure about the syntax yet, since I didn't want to change too much of the original API.

Also: you might notice that I have replaced all references to this with a top-level store object, this way we can reference it in the helper function that creates the namespaced key.

---

Namespacing configuration

I didn't want to create a whole new provider just to be able to configure things in Angular's config() block so I've declared the configuration on the service instead. There are two namespacing options you can set:

• store.namespace which defaults to null (current behaviour)
• store.namespaceDelimiter which defaults to . - this will result in stored keys such as namespace.key

---

Custom/no namespacing syntax

In the store methods, the namespace parameter can either be omitted (default behaviour), null where it will not use any namespace, or a value which will be used for the namespace instead of the default one.

• store.get(name, namespace)
• store.remove(name, namespace)
• store.set(name, elem, namespace) -- This is the syntax I'm not sure about since the other two methods have the custom namespace right after the key name. I think this way is better though, since this behaviour most likely won't be used a lot, and if we moved it to the second argument, people would have to type store.set('someName', null, 'someValue') all the time. Would love to hear your feedback on this.

Created by: mgonto

Hey @thomastuts thanks for the contribution!

I think I'd implement it a little bit different. As you know, services are Singleton in AngularJS. My idea would be to have one Singleton service that lets you store variables in the global namespace, but also lets you create new Stores.

Design would be:

• StoreService (Internal)
  • +namespace (can be null)
  • get
  • set
  • remove
• Store (Angular Service)
  • proxies all of its methods through the internal StoreService instantiated for a null namespace
  • newStore(namespace) ==> Returns a new StoreService for that namespace.

What do you think about this solution?

Created by: mgonto

What do you think of what I've just commited?

Created by: thomastuts

Hey @mgonto, that looks great. I have one small issue with this solution (which might just be a personal thing): it feels sort of wrong that the store now acts as both the default store, and serves as an interface for getting a new store with another namespace. Again, this might be a personal issue and could be totally fine.

Created by: mgonto

Hey.

I don't find it weird, but if you do find it weird, you can create a new storage by just inyecting InternalStore and creating a new object of that. Would that work better for you?

function Controller(InternalStore) {
  var GontoStore = new InternalStore('gonto');
};

closed