Namespaces

[tlaundal]

Adds tooling for namespacing actions so actions from multiple instances of the same "thing" can be separated.

This all works by looking at a namespace property in the meta field of the actions. There are two possible ways to use it:

1. Namespacing an action
   i. Create a namespace (using createNamespace)
   ii. Create a namespaced version of an action (using namespaceActionCreator)
   iii. Use the namespaced action as usual to create action objects and dispatch them on the action$
   iv. Use the filterNamespace streaming operator to filter the action$ for only that namespace
2. Namespacing an action dispatcher
   i. Create a namespace
   ii. Create a namespaced version of an action dispatcher
   iii. Use the namespaced action dispatcher as normal to dispatch actions to the action$
   iv. Use the filterNamespace streaming operator to filter the action$ for only that namespace

[tlaundal]

All comments so far resolved. Will you do final review @chriskr and @anton164 ?

[holographic-principle]

What if meta contains a namespace key? Maybe namespace should be top level? Unless there is a reason for it to live under meta.

[tlaundal]

The tooling controls meta. Our action creators doesn't give the call sites access to meta.
FSA defines type, payload, meta and error as the only allowed top level properties.

In short, I think this is a non-issue, and we have a test verifying that if it should happen, the new namespace takes precedence. This is also documented in namespaceActionCreator.

[holographic-principle]

We shouldn't actually wait for async things to finish in tests. In this case it might not matter much, but I'm sure there are facilities for testing asynchronous things synchronously in tests (i.e. by providing a mock that returns when triggered explicitly).

More importantly though, I don't think we should be testing observables by converting them to promises. I did a quick google search, and this came up (more info here).

I think it's worth investing some time into thinking how we're going to test observables.

[holographic-principle]

AVA is a testing framework with inbuilt support for observables and running tests concurrently. It also works with the aforementioned rxjs-marbles lib.

Looks pretty cool.

I guess you're not too hot for tests and testing frameworks, but I'll just leave this comment here anyway as a note to self.

[tlaundal]

I want to learn more about testing frameworks :)
@anton said he would look into marble testing.

My experience with writing these tests are that the awaits we are using here will only wait for one node tick, and the tests using them does prove something worthwhile about the code. I'm all open for a better way to test them, though!

[tlaundal]

But I think testing strategy and frameworks is out of scope for this PR. Please mention AVA in #14