RiotControl
RiotControl copied to clipboard
jimsparkman
Next version
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?
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 !
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.
so you will make this pub/sub generic? please show some codes as @a-moses suggestion
I'll intro this in a new branch and post back here when I've got some samples together. Thanks much.
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
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?
