Next version

[jimsparkman]

I've rewritten the underlying foundation to remove the dependency on riotjs observable, and it's honestly more generic pub/sub and hopefully a bit easier to understand. I'm hesitant to push this out because people may be relying on the existing API. Anyone with strong opinions?

[a-moses]

Hello @jimsparkman
First of all it is sound very good ! be optimist :)

I'm suggest you just publish the "Next version" on different branch (like your maser and gh-pages) with Alfa or Beta version label.

very important to add a good documentation and example .

after plays with the next version more users could tell what they thinking about more recently

Thank You !

[avanslaars]

I think tagging it and being sure to call out the differences between versions with a strong warning would be safe. That being said, with the more generic application that comes without the Riot dependency, have you considered that maybe this could be seen as a new library with a forked repo, new name, etc. whatever you decide, I'm looking forward to seeing the new version.

[duongphuhiep]

so you will make this pub/sub generic? please show some codes as @a-moses suggestion

[jimsparkman]

I'll intro this in a new branch and post back here when I've got some samples together. Thanks much.

[a-moses]

👍

@jimsparkman

[r4j4h]

All that said, I am excited to see it when finished! :) 👍

[jimsparkman]

I pushed a WIP to a dev branch.

I backpedalled from an initial approach, and turned towards an alternative multi-threaded solution. The API won't be that different in the end, the only difference in the demo was how the store is written. I didn't touch the riot.js view logic.

Stores are automatically launched in separate threads, which encapsulates them from direct access. Also allows for computation off the main UI thread.

This forces a flux-like pattern: user input -> view triggers event -> store(s) do work -> store(s) trigger event -> view updates

[sandrokeil]

This forces a flux-like pattern: user input -> view triggers event -> store(s) do work -> store(s) trigger event -> view updates

@jimsparkman I like this approach. Any news on this?