Has anybody in the client side community ever made the connection to rules engines?<p>This flow of logic is awfully close to how a rule engine works. I wonder if people will at some point arrive at it.<p>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.<p>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].<p>[1] <a href="https://github.com/C2FO/nools" rel="nofollow">https://github.com/C2FO/nools</a><p>[2] <a href="https://github.com/rbrush/clara-rules" rel="nofollow">https://github.com/rbrush/clara-rules</a>
Everytime I see the Flux architecture I wonder what does it bring to the table that a reactive programming library like RxJS or Bacon.js don't? It seems Flux is just hacking together well-defined concepts in these libraries.<p>* Stores could use Observables instead of EventEmitter<p>* Components become Observers by subscribing to Observables which is extremely similar to setting up Listeners.<p>* 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.
Is there a way to get rid of flux boilerplate? I don't want to write three different files (a file with actions, another file with constants, and the actual store). For example, I can achieve the same effect with just a simple array and some functions to modify it. I guess I know what the benefit of embracing flux is, but it still looks too much, and I am mostly lazy.
<i>themgt</i> posted the following on the currently trending React thread, sharing what appears to be Flux's impending sunset:<p><i>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: <a href="http://facebook.github.io/react/blog/2015/02/20/introducing-relay-and-graphql.html" rel="nofollow">http://facebook.github.io/react/blog/2015/02/20/introducing-...</a><p>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.</i><p><a href="https://news.ycombinator.com/item?id=9094255" rel="nofollow">https://news.ycombinator.com/item?id=9094255</a><p>edit: fixed link; thanks!
> If you're like me and you wanted to go further with React, you more than likely would've checked out Flux, had a glance, closed the tab and then reassessed your life as a * developer.<p>This accurately describes my experience yesterday.<p>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.
Heh, this post resonates with me - Facebook's description of Flux drew a wtf when I first looked at the diagrams on <a href="https://facebook.github.io/flux/docs/overview.html#content" rel="nofollow">https://facebook.github.io/flux/docs/overview.html#content</a> with its weird terminology, but when I did some more further research into it, I found out that I had a lot of very similar patterns with my Angular code.<p>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 actually think it's a good to understand Flux in it's purest sense before using a framework. As a learning experiment I created Aqua [<a href="https://github.com/jedireza/aqua" rel="nofollow">https://github.com/jedireza/aqua</a>]. It was published last week and there's a good Q&A thread going on [<a href="https://github.com/jedireza/aqua/issues/2" rel="nofollow">https://github.com/jedireza/aqua/issues/2</a>].
I find the idea of Flux fascinating, but one thing I'm a little curious about is where error feedback fits in here... If an AJAX query fails, or something fails validation, how does this information make its way back to the view? If it happens at the action dispatch level, you still have to pass the event through the store? That seems a little... Odd to me.
Some of the code examples given here are perfect examples of what I hate about javascript.<p>assign(new Dispatcher(), {methodName: function() {}})<p>Why can't I just define a regular class? Even worse, in the following code snippet the arguments seem mismatched with the previous one:<p>assign({}, EventEmitter.prototype, {methodName: function() {}})<p>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.<p>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.
Perhaps a huge coincidence but I pretty much wrote this framework in C# in 2004 (including rules engine) and was using it for mobile devices (wince/symbian). We abandoned it after 4 years for a simple CQRS system with event bus (before Udi/Greg went off on it or Fowler formalised it).<p>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.<p>YMMV but I'd probably start there first. It's much easier than the other two. I might write it up.
It's always nice to read a writeup on Flux.
I would love to hear more about possible isomorphic implementation of the architecture though. Right now besides Fluxible the architecture doesn't play well with server side rendering.
By the way, shameless plug, I wrote an article on Flux (backed by a Rails API) a while ago, if you're interested on the matter: <a href="http://fancypixel.github.io/blog/2015/01/28/react-plus-flux-backed-by-rails-api/" rel="nofollow">http://fancypixel.github.io/blog/2015/01/28/react-plus-flux-...</a>
I've run gulp and then got this error, related to CSS/SASS:<p>Message:
error /Users/gkbonetti/code/flux-getting-started/public/src/scss/partials/_messageBox.scss (Line 3: Invalid CSS after " &": expected "{", was "__list {"<p>"__list" may only be used at the beginning of a compound selector.)
Love going through live examples to learn, thanks for sharing!<p>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?
The author of Reflux argues against having a single dispatcher though: <a href="http://spoike.ghost.io/deconstructing-reactjss-flux/" rel="nofollow">http://spoike.ghost.io/deconstructing-reactjss-flux/</a>
Flux newbies should check out the Reflux implementation.<p><a href="https://github.com/spoike/refluxjs" rel="nofollow">https://github.com/spoike/refluxjs</a><p>One of the best features is that Reflux lets you chain stores to eliminate WaitFor.
Don't people realize that returning HTML instead of JSON will solve their problem for 80% of the use cases?<p>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.<p>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)<p>How does all of this bring Web Development forward? Look at this blog post for example: <a href="http://fancypixel.github.io/blog/2015/01/28/react-plus-flux-backed-by-rails-api/" rel="nofollow">http://fancypixel.github.io/blog/2015/01/28/react-plus-flux-...</a><p>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.<p>Did this get so complicated because front-end development and back-end development is separated at many places?