61–70 of 95 posts
Earlier quoted context omitted.
I'm using Reflux for now, though I'm tempted to switch to something more FRP like Bacon, f, or RxJS. I find that I end up making stores for both AllThings and CurrentThing, and it should be easier to express that relationship with FRP.
I've been using a "FilteredConnect" mixin that I wrote that's solved the "CurrentThing" store problem nicely.
Nice documentation, and dev tools is a big plus. The beauty of flux + react is, it's so simple and flexible. I'm developing a fairly complex application with flux + react, (no flux frameworks, just facebook's dispatcher and stores/actions modelled after facebook's flux examples), and it seems I've implemented lots of things in marty.js. I also started using mixins for subscribing views to stores, immutable data in st…
Great comment and excellent intro to React for interested devs. I've been successfully using React for small and mid-sized apps, and agree that Marty looks like it's an elegant solution to the Flux pattern. (for application state in React, I've also had some success with passing around an immutable cursor, like react-cursor[1]). One cautionary note about how easy it is to integrate React with other frameworks: this s…
The react-cursor library really introduced cursors based on immutable data for me. I've never used the library, but the idea stuck. Omniscient looks very shiny as well, but it too invasively changes the workings of React for me.
Immutable.js provides a great Immutability library, with a very lightweight cursor implementation on top. You can make a simple object that recursively updates itself with the newest state from the cursor. You have to merge updated states at the keyPath to prevent clobbering from 'synchronous' updates at different cursors.
If you give that object a listen(), a getCurrentState() and a private trigger() method, you are well on your way to a complete store. Reflux offers roughly this model, and adds much needed actions and listening to other stores.
Here's a gist with a tightly coupled (incomplete) example store that emits a cursor, and a React component that listens to the store and updates it:
This looks to be a well-put-together implementation of flux. I recently looked over around 20 or so flux libraries to use for a react app I had started, and found only a couple that I liked. I would put this one near the top, but the one I ended up choosing has been great , but no one seems to know about it! If anyone is interested: https://github.com/kjda/ReactFlux It's very similar, but I think I like how Actions a…
But I may switch to Marty since I'm not far along with the project and the dev tools look super helpful.
In Marty: since you attach a Store to a React via a Mixin that looks for a singleton, can you have a dynamic number of stores when you have a dynamic number of React components of the same type?
This sounds like a line from a movie for a character which is the nerd/genius in the movie. I'm not very technical, by the way.
I like ReactJS, but I think Flux is overhyped. One-way dataflow is much better handled via RxJS or BaconJS and as with Om thru cursors. Writing stores and dispatchers and actions is a poor substitute for FRP.
shrug They address different problems. Reactive systems are great but they aren't an overall architectural approach. You have to come up with that yourself. Flux is an architecture. I used BaconJS and I found that my overall page event and data flow ended up being reactive spaghetti. Architecture is not my strong suit. One of the great things about flux is having extremely strong conventions about where everything go…
I found using BaconJS much nicer if I needed to transform data from asynchronous requests because you end up with a much more functional approach.
Earlier quoted context omitted.
Great comment and excellent intro to React for interested devs. I've been successfully using React for small and mid-sized apps, and agree that Marty looks like it's an elegant solution to the Flux pattern. (for application state in React, I've also had some success with passing around an immutable cursor, like react-cursor[1]). One cautionary note about how easy it is to integrate React with other frameworks: this s…
> (for application state in React, I've also had some success with passing around an immutable cursor, like react-cursor[1]). The react-cursor library really introduced cursors based on immutable data for me. I've never used the library, but the idea stuck. Omniscient looks very shiny as well, but it too invasively changes the workings of React for me. Immutable.js provides a great Immutability library, with a very l…
Thus, you can simplify to something like this: https://gist.github.com/Dashed/707664be1319bb222c7c
-------
Omniscient is still useful in that you can make your own `component` shim using their `shouldComponentUpdate()`.
I think the reflux model doesn't too synergize well with immutable-js's cursors. I found out that reflux with omniscient/immstruct ended up being one more level of indirection. Plus, I didn't need all the features that reflux provided. I even tried a super-light version of reflux.
So I replaced reflux with an augmentation upon immstruct with more useful features (a library I've yet to release). I'm still experimenting with it while investigating a nice isomorphic architecture.
Earlier quoted context omitted.
Gaa, another framework that's opinionated about the data structures it gets passed. No thanks.
Try those data structures out. They are based on functional lenses and are really efficient and you can get time travel for free. It's worth trying to understand the data structure and why it was used before you dismiss it out of hand. It was a very deliberate choice. There is also a very strong 1:1 mapping between plain old javascript objects and the state data structure you build up with observ, observ-struct and o…
For example, when implementing a dropdown menu with react, holding the dropdown menu's open/closed state in the component, and modifying it with onClick events is really convenient.
Out of curiosity, for those of you building stuff with Flux: Which library do you use? Or do you just use your own implementation? We recently went with Reflux[1] for our first big React app after reading about it here[2], and I've been pretty happy with it so far. [1] https://github.com/spoike/refluxjs [2] https://reactjsnews.com/the-state-of-flux/
https://github.com/goatslacker/alt
which looks a bit like reflux in terms of terseness but it adds the ability to have snapshots and rollbacks, isomorphism, and it plays real well with ES6.
There's a few of the flux examples that compare flux to alt in the repo. And there are some good isomorphic examples in here https://github.com/goatslacker/iso/tree/master/examples
I'll be posting a write-up of all this pretty soon.
If you like reflux you'll like alt.
Out of curiosity, for those of you building stuff with Flux: Which library do you use? Or do you just use your own implementation? We recently went with Reflux[1] for our first big React app after reading about it here[2], and I've been pretty happy with it so far. [1] https://github.com/spoike/refluxjs [2] https://reactjsnews.com/the-state-of-flux/
This looks to be a well-put-together implementation of flux. I recently looked over around 20 or so flux libraries to use for a react app I had started, and found only a couple that I liked. I would put this one near the top, but the one I ended up choosing has been great , but no one seems to know about it! If anyone is interested: https://github.com/kjda/ReactFlux It's very similar, but I think I like how Actions a…
I also decided to use ReactFlux after looking around at the flux implementations. It kind of suffers from the fact no one knows about it but it feels a lot better to use than the other implementations I looked at. I forked the library to support nested objects in the store state and I'm pretty happy with it now. But I may switch to Marty since I'm not far along with the project and the dev tools look super helpful.
I've done it slightly different than you... rather than using `mergeDeep` in `this.setState`, I created some other methods such as `this.setStateAtPath(path, value)` and `this.mergeState` (the latter would use `mergeDeep`)
I'm going to submit a PR to allow for store mixins to be a little more 1st-class: https://github.com/kjda/ReactFlux/issues/4