This flow of logic is awfully close to how a rule engine works. I wonder if people will at some point arrive at it.
There isn't a whole lot of rules engine in JS. Just nools [1] which is huge. I'd love to see a very simple forward chaining rule engine + Immutable + React and see how that would work out.
My guess is that they aren't popular at all because they have the notion of being enterprisey (Drools/Jboss). I'm a big fan of them. They /can/ make life & code very nice and elegant. Maybe somebody writes an JS adapter to clara rules [2].
You have to wait a while before the JS community realise that enterprisey is just the inevitable end game of their wheel re-inventing.
In the same way they dismiss things they don't understand now due to complexity, they are adding more and more with all these frameworks and architectures.
Nothings new, everythings a remix. I imagine rules engines will be the next "revolution" on this already well trodden road.
[1] https://github.com/rbrush/clara-rules/wiki/ClojureScript
* Stores could use Observables instead of EventEmitter
* Components become Observers by subscribing to Observables which is extremely similar to setting up Listeners.
* Instead of Actions through a Dispatcher, Actions become Proxies (or Subjects in RxJS terms or Buses in Bacon.js terms) that Stores subscribe to and Components push to.
The thing that Flux helps define is how to manage data. We don't have models, but it gives you a coarse structure for your data, with which you can do stuff like data dependencies (derived data), only rerendering part of your UI when parts of your data changes, etc.
How events are used within all of this could certainly be re-purposed with Rx (I've repurposed it as channels myself). You are not wrong, but flux is a bit more formalized with a few more things.
That said, my personal opinion: the deeper you get into a big project the more you'll see the incredible value of the approach. The breakeven between the overhead of learning the approach vs the productivity (and performance improvement) of using it comes pretty early on, in my opinion.
With a lot of software, the more I get deeply into a project the more I feel I'm battling the artificial constraints of the tools I'm using. Flux is exactly the opposite. The deeper I get in, the more I feel it's working for me (and I'm not even using their dispatcher - since I had written my own initially before flux came out, so I can't speak directly to their dispatcher, just the Flux design styling within a React project).
It's very small and removes boilerplate, but still isomorphic.
You end up building a ton of boilerplate code that is capable of handling anything your system evolves into, but most of it is wasted because each part of the system typically only uses a small subset of functionality of the framework. So you're left with a bunch of big crufty systems laying around. When I want to be the most lightweight and agile and capable of changing my direction is at the beginning of a project when I'm still learning how the system will work. These frameworks make it really tough (at least for me) to do that so I end up not using them.
One of the things I didn't realize at first was the degree to which Relay/GraphQL appear to effectively replace a lot of Flux: http://facebook.github.io/react/blog/2015/02/20/introducing-...
Learning Flux sort of seems like learning how to drive stick shift on an '97 Civic while we wait for the new Tesla to arrive - useful, also a bit annoying. A central store architecture does seem a better match to what Relay will look like though.
https://news.ycombinator.com/item?id=9094255
edit: fixed link; thanks!
http://facebook.github.io/react/blog/2015/02/20/introducing-...
This accurately describes my experience yesterday.
I think React is quite expressive in it's simplicity. Flux on the other hand (even though it's good idea), is poorly tooled out.
I think they should have chose some better terminology/words to describe the overall components, in this case I found the words shutting down my thought process on first glance.
I had the same "weird terminology" and "thought stopping" reaction to Angular's, Ember's, and Meteor's architectural terminology. I know they're all trying to differentiate themselves in a crowded market, but its just created more of a mess.
Time for me to go learn a new dictionary, to do the same job I did yesterday.
assign(new Dispatcher(), {methodName: function() {}})
Why can't I just define a regular class? Even worse, in the following code snippet the arguments seem mismatched with the previous one:
assign({}, EventEmitter.prototype, {methodName: function() {}})
I can accept this sort of thing if the payoff is high, like getting access to the performance and simplicity of virtual DOM operations in React, but these examples just seem to be to create basic objects.
Maybe object-assign is one of the javascript best practices that keep changing every 2 months and I'm just not paying attention enough? ES6 can't come soon enough.
[1] https://github.com/goatslacker/alt/blob/master/examples/chat...
assign(some newly allocated object, base class [, base class...], object with methods).
It seems to get around the funny stuff with new, prototypes and references.
You know where we are now? Simple JSON REST API with local and remote queues per device updating a document store. All the queues have on receipt and on dispatch handlers attached and that is it. Each of these can modify the state or perform an external action.
YMMV but I'd probably start there first. It's much easier than the other two. I might write it up.
I wrote my own Flux implementation (back when it was first announced, and there were no/limited libraries for it), and i don't recall having a problem with my implementations.
I probably broke a few rules though, hard to say. I'd be curious to hear your experiences with it :)
Message: error /Users/gkbonetti/code/flux-getting-started/public/src/scss/partials/_messageBox.scss (Line 3: Invalid CSS after " &": expected "{", was "__list {"
"__list" may only be used at the beginning of a compound selector.)
But, I can get it to render (after doing npm/bower install then running gulp), but can't get it to actually do anything. Everything looks right but clicking around and nothing happens? Anyone else running into this?
In short
Traditional MVC: http://www.infoq.com/resource/news/2014/05/facebook-mvc-flux...
vs
Flux: http://www.infoq.com/resource/news/2014/05/facebook-mvc-flux...
edit: or a more complex flux example - http://fluxxor.com/images/flux-complex.png
Trolling aside, Flux really doesn't bring much to the table. It's trying to solve the pain caused by two-way-binding by forcing state to flow in one direction through an event bus, reinventing MVwhatever along the way.
You can already do this stuff in Angular (et al) if you stick to a few firm rules for how to structure your app.
I'm a fairly new developer working in my first post-uni role and we're starting to rack up a lot of Angular code and I'm not sure if I'm structuring things right as far as events vs $watches etc.
https://github.com/spoike/refluxjs
One of the best features is that Reflux lets you chain stores to eliminate WaitFor.
It's similar to reflux but in es6.
Looking at Relay/GraphQL, the whole picture appears as a gigantic layer of indirection to generate a DOM tree, something you could do serverside 10 layers below.
Even 'Components' are just fragments of HTML, retrieving them in the format you want from the server is much easier. And be honest, replacing a fragment of HTML in the DOM is fast enough for most applications. (don't delete form input, though)
How does all of this bring Web Development forward? Look at this blog post for example: http://fancypixel.github.io/blog/2015/01/28/react-plus-flux-...
In 2006, after part 1 you would be done and call it a day. Now I understand that today you need 'realtime' updating. But the "notification count is off by one" Facebook example is really bad, because instead of doing all the math in JS, one can simply do a GET request to fetch the count from the actual Single Point Of Truth, which is your database.
Did this get so complicated because front-end development and back-end development is separated at many places?
The way I did this in some of my apps is that JSON data is shared between web and Android/iOS client, BUT rendering that data into HTML is done server side:
The server detects if the request is coming from the browser or client app. If it's the client app. it just hands over the JSON data. If it's the browser, it uses the same data to render HTML and sends that to the browser.
In general things gets way, way, way more complicated once your system becomes "distributed".
Applications that use streaming data sets tend to use the data for more than just presentation. Does the backend send both HTML and JSON? The backend can't send the entire data set because that's too slow; the client needs to be responsible for maintaining its own copy of the data. What happens when there is a bug and the two sources are inconsistent?
Even if the client doesn't need the data, HTML fragments suck for practicality.
Does your website have any forms? You now have to write a bunch of code to copy the data and preserve the focus. Does your website ever use JS to update the DOM in response to user action? Does your website ever suck in any data from a third party? You now have to compare the state of the DOM (or whatever data generated it) against the HTML fragment and do something sane.
Even if you solve the problem of consistency and applying fragments to the DOM, chances are you will be left with performance problems. You will need to batch updates to control repaints.
Maybe, performance isn't an issue or you solve it, too. Congrats, you just spent man years rewriting React.
Also, you wouldn't apply generating html on the server to everything, on the parts that make sense. If you want to use JS to update part of the DOM (e.g. showing an error that passwords don't match), then you'd obviously use JS. It's completely ok to use the right tool for the right job.
It greatly simplifies development of any but the elementary webapps.
