Potential improvements to state management performance, possibly making it pluggable

[agubler]

@maier49 commented on Fri May 11 2018

For large state stores, things like ImmutableJS are recommended by the redux team as a way to improve update performance. On the other hand ImmutableJS can be quite slow for operations like finding a value.

Making the actual state management portion of the store pluggable would allow a user to implement something that suits their needs without making additional assumptions.

Alternatively, or in addition to this, we could look into general performance improvements such as doing updates in a web worker, since we completely control the "reduction" part of the store life cycle.

[maier49]

I've got a WIP branch where I've ripped out "State" as a pluggable interface in the store, and an ImmutableJS implementation. It's at the point of compiling but not running yet.

That's here: https://github.com/maier49/framework/tree/48-patch-performance

[JamesLMilner]

Some thoughts about putting Stores in a worker

I've been exploring how to put the Store in a worker. @agubler previous attempted this on a branch https://github.com/agubler/stores/tree/store-worker-poc.

I had my own attempt and so far the problems I hit trying to achieve this were:

• Stores is currently a sync API, using a worker forces this to be async for get and apply as a minimum.
• framework uses TypeScript for compliation to UMD. TypeScript currently compiles with to UMD, but has no support for global fallbacks (see umd module compiler option doesn't have a fallback for global namespace. microsoft/TypeScript#8436). This means if your code uses import or export the whole file will be wrapped in a UMD wrapper which in turn means that when you point the worker at the file it never executes. If we want to share code we'd leverage Webpack/Rollup to build a worker specific file with all the dependencies inlined in a bundle.
• Since we can't reuse code (at least not easily) this leads to lots of duplication and potentially inconsistencies in duplicated interfaces. Long term this might actually be quite problematic if they drifted too much.
• I'm not sure what the implications of using a Web Worker having testing with Intern. Might be fine with browser based testing but Node would struggle unless without some mocking I would assume.

My attempts can be seen here:

https://github.com/JamesMilnerUK/framework/tree/worker

Overall my thoughts are it's possible, but it's a bit fiddly and the limitations are a bit annoying. One thing I've thought was offering some sort of Web Worker support via cli-build-app. Here we could define some normalised interface for users to use workers with Dojo, and then they'd be free to put whatever state logic (Stores, Commands, Processes etc) they want in there and it get compiled to it's own worker bundle. This means users would have less thread running on the main thread too, since rather than just Stores, all state logic can run there. The specified code could run in the worker and communicate over the specified Dojo API.

@agubler @maier49 @matt-gadd

[agubler]

Resolved by #242