Aha, I was looking for something along these lines yesterday. One of the nice things so far about Flux so far though has been an absence of much unsettling 'magic' in the stack, which you get in Angular and Ember.
Will definitely check this out though, it seems sensible.
Does anyone know of a library like this which plays nicely with TypeScript's type checker? I've not come across a way to avoid the use of essentially un-typed string keys in cursors like this.
Hello DougBTX. Could you post an issue on the repository describing what you would need for this library to work nicely with TypeScript so we can see whether things can be improved?
After implementing Facebook's stock Flux (actions + constants + stores + dispatchers + views), which quickly gets verbose, I saw this on r/reactjs the other day and started playing with it and so far I've been impressed.
It takes some getting used to, but the mixins help reduce your code to actions + store + views and make it easier to reason about. There's a good post about it, including simple server integration, here:
I have only briefly checked out this library so take what I say with a grain of salt, but from what it looks like we had a very similar implementation to this on the project i'm currently involved with, also very inspired by Om.
At first it worked out great for us but as our application grew both in scope and number of developers involved, we quickly ended up with a 'cursor soup' where too many components were watching for changes individually.
It had a very negative impact on performance since components would potentially re-render multiple times for a single change. In our last implementation we ended up overcoming this by some fancy event consolidation, but even so we had too many components 'touching' our tree.
We ended up reverting to a much simpler architecture and it has both made our application dumber (which is great in terms of maintenance) but also more performant. We currently have actions/stores/views where actions themselves are dispatchers. By creating a few helper functions we overcome a large part of the boilerplate but even without, it has proved worth it for us.
I've been thinking about cursors and the potential for this problem, too. In your experience would you say that a strict flux pattern utilizing the PureRenderMixin and immutable data is a better way to go, and that one should avoid cursors completely for larger projects? It might be my lack of understanding, but cursors bring me back to some of the more annoying aspects of MVC, namely the potential for not knowing what is going on where.
Obviously everything I say is anecdotal since I have no data to share but by making components as dumb (i.e. PureRenderMixin) we reduced the amount of logic within a component and were able to make it both faster and easier to maintain. Maybe our approach was naive and Baobab fares better here.
Another important gain for us was re-usability of components. We have several projects that use the same components that represent the same data but the hierarchy of the internal state of the application can look quite different from one another. Passing everything in as props and avoiding as much state as possible has made this much easier as well.
I guess at the end of the day everything is a tradeoff one way or another and you just have to pick yours, as cliche as that sounds. For us simplicity was more important in this particular case.
"When you use the mutation methods of Baobab (push, set, merge etc.) it will batch up these changes and make one single commit, which then triggers update events."
I haven't worked with Om on a non-trivial project yet, so please correct me if I'm wrong, but I believe Om might also do similar optimizations (i.e. batching updates and sending notifications in sync with its render on requestAnimationFrame flow).
I believe the idiomatic way to use this library is to treat the tree as an immutable structure. When used this way, it supports the React Immutability Helpers, and the PureRenderMixin. If you treat it as immutable and use the PureRenderMixin, you won't run into the re-render multiple times issue described above.
I haven't read the whole article that you linked, but the diagram seems very similar to Reflux, except that it uses the state tree instead of stores. Have you tried Reflux, if so how would you compare the two?
Reflux[1] is another Flux alternative without the verbosity of Flux. I have no affiliation to the project, but use it in two of my current projects and am deliriously happy with it
Can someone explain what problem this solves that just using flux can't? I'm having trouble understanding how a tree structure is useful, because I can imagine different actions affecting different stores in different orders. So I wouldn't want changes to only bubble up, sometimes I would need them in the other direction.
I found David Nolen's talk at React conf useful in understanding the motivation for cursors. https://www.youtube.com/watch?v=5hGHdETNteE. See in particular starting around 15:40. Cursors are used when you are strict about global immutable state; whereas Flux (like React itself) is agnostic about this. IMO this agnosticism means you end up with a more complex architecture. David's point in the video is, even with cursors and immutable state atoms, you end up with a parallel set of complications to deal with -- around questions of inter-component communication across nodes of the tree and information hiding. He sketches Om's current solution to this using observable cursors which kind of let you trace data-change dependencies between components - but I have to say without understanding Om better it's a bit hard to follow.
I found Baobab to be really helpful by letting me focus on the application logic, rather than implementing 1000 things to conform to a pattern. I'm not saying that Flux is unnecessary, but I think it can be improved and this is a nice direction, which conforms to the basic idea, if I get it right.
A blog post[1] from Christian Alfoni with some examples helped me get started with it. The tree becomes a nice summary of your application which makes it easier for someone new to your project to make sense of it. Also there's another post about going isomorphic with it[2], which is intriguing.
There's already a fairly major software project (it's installed on a significant portion of Linux desktops) called Baobab, part of the GNOME desktop environment[1]. Not saying that software needs to have a unique name, but "Baobab", a type of tree, is a pretty distinctive sounding name that people would expect to be unique just because of how unorthodox it sounds. I can imagine people getting confused.
I don't think that anyone may confuse a react javascript library with the Gnome Disk Usage Analyzer. Yet, being the author of Baobab the PHP library (http://www.sideralis.org/baobab/), I would have preferred a different name :-P
Can someone explain the advantages of using this over mori (which doesn't include cursors per se at the moment, but are easy to implement on top of mori data structures)?
Yah. I don't know ClojureScript but that doesn't stop me from using it. And David Nolen pretty convincingly addressed the size question in "Javascript Modularity Shaming"[1] - i.e.: use Google Closure Compiler.
Watching ideas flow from the Clojure/Script community back into Javascript I'm reminded of the positive impacts the Rails community had on Java web development. I guess we're at that point in time with respect to Javascript.
Impressive. I imagine it being useful in almost all my projects. But how fast is it? Is using `shiftReferences` to enable pre-rendering comparisons a good idea?
A superficial and perhaps temporary difference is "for performance and size reasons baobab does not (yet?) use an immutable data structure", whereas immstruct wraps immutable-js.
I'm curious if there are other differences though because at first glance they seem to be separate implementations of similar ideas.
IMHO, JSON can be seen as the simplified, fat-free child, non Enterprise-Edition of XML; where features are created out of popular demand -as opposed to being created by committee decision-.
So this is kind of a special-purpose Bacon.js stream processing library that has one central Property that all events flow into and out of? I might not be making any sense, this stuff is all new to me. Thanks for any clarification!
30 comments
[ 3.0 ms ] story [ 86.8 ms ] threadWill definitely check this out though, it seems sensible.
It takes some getting used to, but the mixins help reduce your code to actions + store + views and make it easier to reason about. There's a good post about it, including simple server integration, here:
https://www.codementor.io/reactjs/tutorial/flux-reactjs-stat...
I was surprised at the lack of attention it got, but I hope that changes because there are some good ideas here.
At first it worked out great for us but as our application grew both in scope and number of developers involved, we quickly ended up with a 'cursor soup' where too many components were watching for changes individually.
It had a very negative impact on performance since components would potentially re-render multiple times for a single change. In our last implementation we ended up overcoming this by some fancy event consolidation, but even so we had too many components 'touching' our tree.
We ended up reverting to a much simpler architecture and it has both made our application dumber (which is great in terms of maintenance) but also more performant. We currently have actions/stores/views where actions themselves are dispatchers. By creating a few helper functions we overcome a large part of the boilerplate but even without, it has proved worth it for us.
Another important gain for us was re-usability of components. We have several projects that use the same components that represent the same data but the hierarchy of the internal state of the application can look quite different from one another. Passing everything in as props and avoiding as much state as possible has made this much easier as well.
I guess at the end of the day everything is a tradeoff one way or another and you just have to pick yours, as cliche as that sounds. For us simplicity was more important in this particular case.
https://github.com/Yomguithereal/baobab/wiki/Options
"When you use the mutation methods of Baobab (push, set, merge etc.) it will batch up these changes and make one single commit, which then triggers update events."
I haven't worked with Om on a non-trivial project yet, so please correct me if I'm wrong, but I believe Om might also do similar optimizations (i.e. batching updates and sending notifications in sync with its render on requestAnimationFrame flow).
See this issue for more details: https://github.com/Yomguithereal/baobab/pull/74
[1] https://github.com/spoike/refluxjs
I am unclear what this lib brings to the table.
A blog post[1] from Christian Alfoni with some examples helped me get started with it. The tree becomes a nice summary of your application which makes it easier for someone new to your project to make sense of it. Also there's another post about going isomorphic with it[2], which is intriguing.
[1]: http://christianalfoni.github.io/javascript/2015/02/06/plant...
[2]: http://christianalfoni.github.io/javascript/2015/03/01/true-...
[1]: https://wiki.gnome.org/Apps/Baobab
[1]: http://swannodette.github.io/2015/01/06/the-false-promise-of...
A superficial and perhaps temporary difference is "for performance and size reasons baobab does not (yet?) use an immutable data structure", whereas immstruct wraps immutable-js.
I'm curious if there are other differences though because at first glance they seem to be separate implementations of similar ideas.
So far, we have:
XML -> JSON
BaseX, eXistdb -> MongoDB, RethinkDB
XSD, DTD -> JSON Schema
WSDL -> HATEOAS
XML-RPC -> JSON-RPC
XPath -> JSONPath
xmlns -> JSON-LD
SAX -> clarinet
--------------------
Would we have:
XSLT -> Baobab ?