9 ms·

Marty.js – A JavaScript library for state management in React applications

255 points by jfhollingworth 12y ago

bryanlarsen 12y ago
I've been using fynx[1], and it seems to work for me so far. What attracted me to fynx was that it uses Facebook's immutable-js[2] for its stores. It would be nice to get an updated version of this comparison of available flux libraries[3]. 1: http://foss-haas.github.io/fynx/ http://foss-haas.github.io/fynx/ 2: https://github.com/facebook/immutable-js https://github.com/facebook/immutable-js 3: https://reactjsnews.com/the-state-of-flux/ https://reactjsnews.com/the-state-of-flux/
riffraff 12y ago
In http://martyjs.org/guides/flux/index.html http://martyjs.org/guides/flux/index.html it says > thanks to action types being strings you have a loosely coupled Law of Demeter architecture which is easy to grow without increasing the complexity of the code base. I don't see the connection between cause and effect, unless this is saying "since everything is in the global state there is no coupling". Seems odd.
rattray 12y ago
This looks great. The docs really are terrific, too. Personally, I've been playing around with Bacon.js (or RxJS) instead of the Flux dispatcher. Using `Bacon.update` in conjunction with Facebook's Immutable.js seems really promising. The outcome is a far more functional approach. A quick and dirty example: https://gist.github.com/rattrayalex/dee40d86813bcaa9de80 https://gist.github.com/rattrayalex/dee40d86813bcaa9de80
- RobertKerans 12y ago
  Thanks for posting that, I've just been trying to get something similar to work using Bacon, and was looking for some examples of how to approach it.
- colinramsay 12y ago
  It took me a second for this to click but it looks fantastic. It'd be good to follow this up with a larger example - what are the issues you foresee?
  - mjohn 12y ago
    I recently used React + Bacon + Immutable in a small project and I haven't come across any issues yet. I haven't seen any larger-scale examples yet, but this blog post[0] was interesting and has links at the bottom to implementations of todomvc and the flux-chat example. [0] http://blog.hertzen.com/post/102991359167/flux-inspired-reactive-data-flow-using-react-and http://blog.hertzen.com/post/102991359167/flux-inspired-reac...
    - rattray 12y ago
      That post's code provided inspiration for this! Though I found their examples a bit over-engineered for my taste...
  - rattray 12y ago
    Hopefully you'll see a blog post from me on this in the coming weeks =) I'm a little worried about finding a good answer to the Flux Dispatcher's elegant `waitFor`, but I have a few ideas that I think could handle that well. I'm also worried about "stream spaghetti", especially having streams defined outside of a central `Actions.js`. I'm not yet sure how to elegantly handle server-syncing, though again, I have a few ideas (and Marty seems to provide some too). Lastly, I don't know the performance characteristics of Bacon or RxJS.
- computmaxer 12y ago
  Have you considered omniscient with Immutable.js? https://www.npmjs.com/package/omniscient https://www.npmjs.com/package/omniscient
  - Touche 12y ago
    Last time I looked the combination of all of those frameworks is quite large (like 400k+ IIRC).
  - rattray 12y ago
    It was the inspiration for my current setup, actually! Ultimately, pure-Bacon seems more functional, and I wanted to use something where all the "primitives" (Immutable, Bacon, etc) can be used directly, and are extremely well-supported. I may add a few abstractions (eg; a basic Mixin for event-binding, along the lines of [0]), but would prefer not to have a framework that "does too much" or has much magic, at least until it's very widely-used. [0] https://www.npmjs.com/package/fluxbone https://www.npmjs.com/package/fluxbone
- dugmartin 12y ago
  Interesting use of a bus for each action. I'm curious why you used @setProps() instead of just storing the person object in the component state? Modifying props seems a like non "Reactish".
  - rattray 12y ago
    Actually, I think you've changed my mind on this. The reason is that I'm coming from a React/Backbone background (see [0]), where the Backbone Model was passed in as a prop, and then also listened-to within the component. So in that context it would make more sense for it to be `props` instead of `state`. In this case, you can't really pass the person object in as props and then listen to it for changes from within the component, since the object is different from the stream "emitting" it. When the emitter and the object are different things, it makes sense that the emitter comes from `props` (or is directly `require()`'d, which may be an anti-pattern?) and the object is set in `state`. [0] http://www.toptal.com/front-end/simple-data-flow-in-react-applications-using-flux-and-backbone http://www.toptal.com/front-end/simple-data-flow-in-react-ap...
peterjmag 12y ago
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 https://github.com/spoike/refluxjs [2] https://reactjsnews.com/the-state-of-flux/ https://reactjsnews.com/the-state-of-flux/
- mjohn 12y ago
  I really like Reflux as well. In a recent project I used Bacon.js[1] to create my own implementation that ended up looking similar to Reflux. The project involved asynchronous requests triggered by the actions, and transforming & aggregating the returned data. Compared to Reflux, Bacon made it very easy to do this by composing small functions that are applied sequentially to a stream of actions. [1] https://baconjs.github.io/ https://baconjs.github.io/
- bsimpson 12y ago
  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.
  - kylemathews 12y ago
    I've been using a "FilteredConnect" mixin that I wrote that's solved the "CurrentThing" store problem nicely.
    - bsimpson 12y ago
      Interesting. Link?
      - kylemathews 12y ago
        Still private — need to create a pull request against Reflux.
colinramsay 12y ago
I'm scanning the documentation for this now and the "state sources" concept looks useful. Stores seem to be a bit cleverer than in other Flux implementations too. The fact it's got a Chrome extension and what appears to be comprehensive documentation bodes well. I'm currently using reflux because I like its simplicity (no dispatcher and no action creators) but Marty has definitely piqued my interest. Edit: Question for the author. Any thoughts on isomorphic apps with Marty? Edit2: Answering my own question: https://github.com/jhollingworth/marty/issues/13 https://github.com/jhollingworth/marty/issues/13
- glifchits 12y ago
  General impression is the same. I'm using Reflux and quite happy with it, but this does seem pretty smart. Having built in rollback of actions is nice, and having the versatility of where-queries to invoke action handlers is interesting. Not sure if its worth the switch, there aren't really pain points to be solved here... but my next React project might use this.
- jfhollingworth 12y ago
  Isomorphic apps are the next big challenge. Right now the biggest blocker is that everything's a singleton. I'm working on an internal container which should hopefully mean existing apps can be made isomoprhic without a change to the API
  - btown 12y ago
    I've found that contexts are a good way to handle this - they're basically invisible props that get implicitly passed down the component tree, and mixins can whitelist which parts of the context they want to be able to use. They're undocumented, but they're used quite widely in React, so I doubt they're going anywhere. You can have a top-level component instantiate new dispatchers and stores and expose them as i.e. "this.context.userStore", "this.context.dispatcher" to mixins and component code. And this can be done concurrently in the same Node process without needing VMs/sandboxing. Your state mixin API might need to change a bit, but it can be substantially the same: var UserState = Marty.createStateMixin({ listenTo: "UserStore", getState: function (UserStore) { return { users: UserStore.getAll() }; } }); A reference: https://www.tildedave.com/2014/11/15/introduction-to-contexts-in-react-js.html https://www.tildedave.com/2014/11/15/introduction-to-context... Fluxxor, FYI, bundles all of this in context.flux: https://github.com/BinaryMuse/fluxxor/blob/master/lib/flux_mixin.js https://github.com/BinaryMuse/fluxxor/blob/master/lib/flux_m...
oliverwoodings 12y ago
I've contributed to this project on the state sources. For me Marty is the best Flux implementation available right now. When reviewing other frameworks I found them to be either too restrictive by imposing non-flux limitations or the complete opposite by not implementing the flux principles well enough.
dengar007 12y ago
This looks fantastic. Great work on the documentation too!
agilebyte 12y ago
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?
- dalacv 12y ago
  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.
  - egeozcan 12y ago
    I try to do my best to follow the trends in JavaScript development and do mostly develop with JavaScript and even I can't keep up with the new terminology these days. When looking at marty.js documentation, I was constantly trying to map the new concepts to the ones I already know about.
  - elwell 12y ago
    Would make sense given Marty is a reference to Marty McFly from Back to the Future; having to do with state management through time and, of course, Flux capacitors.
    - bronson 12y ago
      And it wouldn't be the first time: https://github.com/kenwheeler/mcfly https://github.com/kenwheeler/mcfly
prottmann 12y ago
Can't see a difference between marty and fluxxor. The examples look for me the same, except some additional functions to declare things.
- oliverwoodings 12y ago
  A first look at the examples for both projects would give you that impression. Some areas that Marty differs in: - State sources: http://martyjs.org/api/state-sources/index.html http://martyjs.org/api/state-sources/index.html - Contants are handled more intelligently: http://martyjs.org/api/constants/index.html http://martyjs.org/api/constants/index.html - Dev tools: http://martyjs.org/devtools/ http://martyjs.org/devtools/
- jfhollingworth 12y ago
  Author here. I found that no other Flux implementation really helped with fetching data in a Fluxy way. There tended to be a lot of boiler plate code for binding stores to components. Furthermore, there was a lack of tooling for debugging. Marty helps combat these issues by introducing a number of new things: - Fetch API for fetching data asynchronously without callbacks http://martyjs.org/guides/stores/fetching-data.html http://martyjs.org/guides/stores/fetching-data.html - State Mixins for binding stores to views http://martyjs.org/api/state-mixin/ http://martyjs.org/api/state-mixin/ - State sources for syncing state from heterogeneous sources http://martyjs.org/guides/state-sources/index.html http://martyjs.org/guides/state-sources/index.html - Chrome Developer extension (beta) for visualising the data flow and state of stores http://martyjs.org/devtools/ http://martyjs.org/devtools/
  - prottmann 12y ago
    Thanks, i will have a closer look. The integrated data fetching and data flow extension sounds interesting, at the moment i use superagent with the mentioned callbacks and events to visualize (it is not comfortable).
  - bsimpson 12y ago
    Like many others, I've been using Reflux because it seems to be the easiest to understand and to work with by reducing the surface area of concepts you need to understand to just: 1) actions 2) stores. In Reflux, a store is effectively just a variable you want your component(s) to be able to access and an action is a function that tells the store what to change about its state. For instance, I might have a CurrentUser store that tracks who the current user is and notifies my Profile component when that changes. I might also have a switchUser action that tells CurrentUser to change its state to user #30. That's all you need to understand to use Reflux. It's certainly interesting to have data fetching baked into Marty, but it also introduces so many concepts. I think it'd be really helpful for people coming from other libraries if you had a big glossary that says what each thing is and why you felt a need to include it. What's a Marty constant and why is it different than an action creator? What purpose does the dispatcher serve? etc. You'd have a better time recruiting and training new users with a diagram that shows how all these concepts fit together and why you need so many of them.
hakanderyal 12y ago
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 stores (so undo/redo is available without much work), loading data into stores from different sources etc. I believe, in the following months, a de-facto flux framework will emerge, and marty looks so close to being that framework. A few tips to fellow developers want to try react and/or flux: - React is just the view part. Integrating it with other frameworks is easy, and integrating other js libs with react is also easy. - OTOH, if you want to build a whole complex app with react, use something like flux with it, since there isn't a flexible way to modify the app state from child components with react. - Immutable data structures really goes well with react + flux. I haven't been able to get the immutability/functional style before, and react + flux really helped with that. Thanks again for the great tools.
- eric_bullington 12y ago
  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 statement is true as long as the framework in question doesn't touch the DOM (e.g., using Backbone models). But if you try to integrate React with any JS library or framework that mutates the DOM, you should be aware that this will interfere with React's DOM "accounting" and potentially cause lots of problems. There are certainly ways around this (look into the lesser-used React life cycles), but it's much easier to stick within the React ecosystem for any libraries that manipulate the DOM, or build your DOM manipulations from scratch (easy to do with React). Already, there's a fairly feature complete React Bootstrap library [2]. I've started work on a React charting library, using d3 for path calculations and other utilities (and temporarily for chart axes generation, but library users shouldn't have to worry about any DOM issues) [3]. And I'm sure there are a thousand and one other React view-level component libraries I'm not familiar with, most of which are likely available via NPM. But I agree that React and the other virtual DOM libraries and frameworks (Ractive, Mercury, Om, etc.) are the next generation approach for client-side views. They not only make DOM manipulations much snappier, but they also make them much easier for the developer. 1. https://github.com/dustingetz/react-cursor https://github.com/dustingetz/react-cursor 2. https://github.com/react-bootstrap/react-bootstrap https://github.com/react-bootstrap/react-bootstrap 3. https://github.com/esbullington/react-d3 https://github.com/esbullington/react-d3
knivets 12y ago
Make for building — interesting.
picardo 12y ago
Nice documentation. But I don't see anything groundbreaking here. The whole rationale for Flux is to unidirectional state flow, and it does that quite well. A lot of library creators have focused on the tiny quibbles with "ease of use" around stores and constants –– "state management" is a good euphemism for this need –– but that's not really a bottleneck for me. I can manage my constants manually with Flux, and add listeners myself. If I need to indicate a dependency between to stores, I can use a waitFor in the switch/case block. It's that simple. Why should I learn a bunch of abstractions that make only an incremental difference? My only pet peeve with Flux is that it does not let me dispatch from within an ongoing dispatch, which is not a huge deal yet because you can just defer the callback to the next event loop, but it's not allowing me to pipeline actions as I thought it should. I have to wait for the stack to empty out before I can dispatch a new action, which sucks. Also, there is no indication as to when a dispatch is over, so I am deferring dispatches by instinct –– or wrapping them in a promise might be the same thing.
- jfhollingworth 12y ago
  Hey, author here. This is a repeat of my answer below but it's right down the bottom so might be missed: I found that no other Flux implementation really helped with fetching data in a Fluxy way. There tended to be a lot of boiler plate code for binding stores to components. Furthermore, there was a lack of tooling for debugging. Marty helps combat these issues by introducing a number of new things: - Fetch API for fetching data asynchronously without callbacks http://martyjs.org/guides/stores/fetching-data.html http://martyjs.org/guides/stores/fetching-data.html - State Mixins for binding stores to views http://martyjs.org/api/state-mixin/ http://martyjs.org/api/state-mixin/ - State sources for syncing state from heterogeneous sources http://martyjs.org/guides/state-sources/index.html http://martyjs.org/guides/state-sources/index.html - Chrome Developer extension (beta) for visualising the data flow and state of stores http://martyjs.org/devtools/ http://martyjs.org/devtools/
  - picardo 12y ago
    You're right about the boilerplate. I use a wrapper around React.createClass to take care of that. Kinda similar to Marty.createStateMixin, but it's just a component factory. The Chrome plugin looks very nice, but you can do the same thing with console.log() outputs in your store. It's a nice to have, but not filling a need for me.
chadscira 12y ago
Does marty.js support the concept of an app context? The only implementation i know of is Yahoo's fluxible (https://github.com/yahoo/fluxible https://github.com/yahoo/fluxible). This is mainly useful when you're trying to render your flux app on the server.
- jfhollingworth 12y ago
  Not right now but isomorphisim is the next big feature I'm going to be working on
  - chadscira 12y ago
    Awesome, i have been in search for a good solution for isomorphic flux implementations.
jordanlev 12y ago
This looks really neat, and the documentation does seem nice. What I would absolutely love (and I'm sure many others as well) is a tutorial that shows how to build a very simple app from scratch... like a list of records and then click on a record to bring up an edit form (something super basic, but a tad more complex than TodoMVC). The problem I have is wrapping my head around how I put all the pieces together. Thanks!
corford 12y ago
Slightly OT but has anyone tried Marionette + React as a combo? Would be very interested to hear how smoothly (or not) it went.
lrichardson 12y ago
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 https://github.com/kjda/ReactFlux It's very similar, but I think I like how Actions and subscriptions to actions are handled with it better.
- UberMouse 12y ago
  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.
  - lrichardson 12y ago
    Funny... I actually created some store mixins to do the exact same thing. 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 https://github.com/kjda/ReactFlux/issues/4
rpwverheij 12y ago
I'm using react quite a lot, but with my own API / storage solutions. So far I'm not really familiar with flux, and also with this, just quickly looking at it, I don't understand if/why I would need it. I can't really wrap my head around what exactly all this allows me to do and can't bring up the effort to read all the docs. I think I'll read more about flux first at some point, and if I'll ever want to use that, come back and check Marty :) Happy to see active react development though
- zachallaun 12y ago
  If you haven't seen it yet, they have a nice Flux write-up in the docs: http://martyjs.org/guides/flux/index.html http://martyjs.org/guides/flux/index.html. (I apologize if you've already seen it, though.)
- jasim 12y ago
  In your typical React component, you'll keep state in the parent, and pass them down as props to the children's subtrees. You also have to pass down handlers (`handleNameChange` for example) along with the props so that the child components can change the state. These handlers travel back to the parent, modify the state there, which triggers a re-render, and that travels from the parent down all the way to all the children again. This works for most use cases. This however forces you to keep all your model logic (computation, transformation, validation and server-communication) in the parent view component. So you'll extract a Model out of it, in which you keep all this data and logic. All the handler methods in the parent component would then call the mutation methods in this model instead of changing the component state directly. But now you need to ensure that the component state is consistent with the model state, for which you hook into the Model's onChange callback in the component's `componentDidMount` method. This means whenever the Model mutates, the component state changes accordingly. For example, if you have a `setPageTitle` method in the Store (that's what we call our Models in Flux), the store would mutate the value when `setPageTitle` is invoked, and call its own `emitChange` method, which triggers the `onChange` callback on the component which was registered during its `componentDidMount`. See: https://github.com/facebook/flux/blob/master/examples/flux-chat/js/components/ThreadSection.react.js#L34 https://github.com/facebook/flux/blob/master/examples/flux-c.... You use EventEmitter (I prefer EventEmitter3) on the Store to make it an observable. See: https://github.com/facebook/flux/blob/master/examples/flux-chat/js/stores/ThreadStore.js#L56 https://github.com/facebook/flux/blob/master/examples/flux-c.... The first step in Flux is this: a simple View-Model separation using an EventEmitter store. Apart from the View-Model separation, this lets you share global state between multiple components. (Global state is bad for programmers, but the real world doesn't care. There are instances where you need to share the same data between multiple components and have them all update automatically) In the ThreadStore example I linked to above, the `emitChange` method is called only through the Dispatcher at the bottom. This is the next step: we do not let any component modify the store values directly. Everything is channeled through a uni-directional dispatcher. The reason to do this is to avoid one Store talking to another Store talking to another, and each of these causing cascading state changes in the components that observe them. So instead of having multiple intertwined paths to the Store, you force the entire application to go through a single-channel dispatcher that process each Action in sequence. The Actions are simply constants that are available globally to invoke specific behaviour across one or many stores. Each Store watches out for the Actions (a constant pushed into its mesage bus) they are interested in, and calls the appropriate method in its body. You push the Actions into the dispatcher, who is responsible for sending it to each Store. The dispatcher uses the same EventEmitter observable pattern to bind each Store to the actions they are interested in. Written in a hurry, but I hope it helps. The flux-chat repo (https://github.com/facebook/flux/blob/master/examples/flux-chat https://github.com/facebook/flux/blob/master/examples/flux-c...) is a great place to understand the entire pattern.
kuni-toko-tachi 12y ago
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.
- grandalf 12y ago
  A few questions: - What is the equivalent of the global action bus in Flux? - How do you handle consuming data from multiple rest endpoints? - Suppose you want to restructure the components in the app into a different hierarchy, how much refactoring is involved? - Is there any open source example code of an app built this way that is more complex than a simple todo or simple async example? (I think the biggest challenge with these kinds of apps comes at that next tier of complexity... it's trivial to do a clean TODO implementation that doesn't do anything with server data in nearly any framework).
  - hakanderyal 12y ago
    In flux, all the data are stored in stores. When a component needs data, it subscribes to the relevant stores, and updates itself on data changes. When you want to mutate the data, you call an action, which in turns mutate the data in the store. Since the components are subscribed to stores, they get the new data automatically. Stores subscribe to a central dispatcher, listening to all actions. When an action fires, they look the action's data, and mutate their data if it is relevant to them. The data flow is action-> dispatcher-> store -> component -> action. When you want to get data from a rest endpoint, you fire an action from the component. The action fetches the data, and pushes it to dispatcher.
    - grandalf 12y ago
      I know how this works in Flux, but wondering how it works using the approach w cursors.
- tel 12y ago
  Obligatory Bacon.js and RxJS are not FRP but merely RP statement.
goatslacker 12y ago
Congrats, the site looks really nice and the devtools feature is great!
daveidol 12y ago
One thing I would love to see some guidance on with Flux (and potentially with the patterns expressed in Marty.js) is how to handle the use case of Stores for a collection of items as well as a single item. Right now, if I create a Store for a collection of Users and I want to be able to mutate these User objects then I create actions for each CRUD mutation and then plumb that change through to the in-memory object inside my collection as well as persist the change to my server. But as soon as I click on a specific User and load up a new page for that User, for example, then I need to create an all new Store just for a single User, which has all of the same mutations/actions available to it as the previously-mentioned collection Store (except now I don't need to pass the ID to every action payload). The best approach I've seen on this topic is in this example's Readme: https://github.com/gaearon/flux-react-router-example https://github.com/gaearon/flux-react-router-example Does this approach make sense/jive with the Marty.js way of handling Stores, State Sources, etc?
- hakanderyal 12y ago
  The method that you linked is the one I use currently. Another way is to use a nested immutable data structure (something like immutable.js[1], react-cursor[2]), use only one store, and make all changes on this data structure and pass accordingly. Even if you don't use immutable.js, I strongly suggest to use immutability with react update[3] or equivalent. Things get way easier that way. [1]: https://github.com/facebook/immutable-js https://github.com/facebook/immutable-js [2]: https://github.com/dustingetz/react-cursor https://github.com/dustingetz/react-cursor [3]: https://facebook.github.io/react/docs/update.html https://facebook.github.io/react/docs/update.html
  - daveidol 12y ago
    Thanks for the suggestions. I've looked at immutable data structure libs some, but I haven't seen any real comprehensive examples showing the behavior you describe within the Flux pattern. Do you happen to know of any such examples? I ask because the examples I see for react-cursor, etc typically show data being mutated directly inside the React component without using Actions/Stores/etc. Going this route means we lose the advantages such as a unidirectional data flow & the ability to centralize logic for interacting with a Store around well-defined Actions. So if we did merge the Flux idea with Cursors, I assume we would keep a single Cursor as the underlying state inside a Store, and then use the traditional Action/ActionCreator model to allow React components/server updates to mutate this Store? What is the big win here then vs. traditional (non-immutable) Stores (other than performance gains by using === in shouldComponentUpdate)? It seems to me you would still have to make a separate Store for editing a single item vs editing a collection.
STRML 12y ago
This seems very similar to Fluxxor, but solves some of the pain points. Stores need to be extendable, and the Mixin concept (as used in React Elements) are a very useful way to do it. In this way, one can easily implement Marty's "State Sources" concept. I released a fork of Fluxxor a while ago with Mixin support [1] but it is unlikely to make it until 2.0. The other nice parts to my eyes are: State Mixins - sort of a hybrid between Fluxxor's StoreWatchMixin and Fluxxor-autobind [2] Constants - This is a new one, I like it. Will have to play with it to see if it truly solves any problems; I've found that when I need to know what actions are available, I scan my actions files, simple as that. Marty seems a little more "batteries included" than the other Flux implementations on the scene. This is a good thing, so long as it is easy to extend. Unfortunately I still don't see Mixins in Marty Stores either. In my opinion they are required for non-trivial apps. 1. https://github.com/STRML/fluxxor/tree/storeMixins https://github.com/STRML/fluxxor/tree/storeMixins 2. https://github.com/STRML/fluxxor-autobind https://github.com/STRML/fluxxor-autobind
- jfhollingworth 12y ago
  Author here: Marty stores do have mixins, think I forgot to add them to the docs
  - STRML 12y ago
    Great! That's a big plus for me.
thomasfl 12y ago
Even if HN readers are getting tired of all the new "Javascript librairie de jour", it's really exciting to see how new techniques are refined and improved in a fast tempo. Keep them libraries coming!
joesb 12y ago
I really want to use React in my next application, but I'm lost on how to do visual things like animation (like a carousel), drag-drop, typeahead. Do you have any suggestion on the best practice on doing those heavy DOM stuff in React? I know I can use jQuery for that, but it feels wrong to me. Also how do you handle integrating React with command based JS library, where your only interface to it is to call mutating functions, such that you cannot blindly rerender the whole things. Suggestions on these two issues would help me greatly.
joesb 12y ago
I really want to use React in my next application, but I'm lost on how to do visual things like animation (like a carousel), drag-drop, typeahead. Do you have any suggestion on the best practice on doing those heavy DOM stuff in React? I know I can use jQuery for that, but it feels wrong to me. Also how do you handle integrating React with command based JS library, where your only interface to it is to call mutating functions, such that you cannot blindly rerender the whole things. Suggestions on these two issues would help me greatly.
joesb 12y ago
I hope all the virtual-DOM based library comes to concensus with one based virtual-DOM library, or that it becomes part of the browser standard. I don't mean the whole React library, I mean just "this a the DOM before, here's the change, now patch it" part. More and more framework and UI library are going to be built around vritual-DOM concept. I don't want integration nightmare of UI-libraries working only on some React-like library.

255 points by jfhollingworth 12y ago

I've been using fynx[1], and it seems to work for me so far. What attracted me to fynx was that it uses Facebook's immutable-js[2] for its stores. It would be nice to get an updated version of this comparison of available flux libraries[3]. 1: http://foss-haas.github.io/fynx/ http://foss-haas.github.io/fynx/ 2: https://github.com/facebook/immutable-js https://github.com/facebook/immutable-js 3: https://reactjsnews.com/the-state-of-flux/ https://reactjsnews.com/the-state-of-flux/

riffraff 12y ago

In http://martyjs.org/guides/flux/index.html http://martyjs.org/guides/flux/index.html it says > thanks to action types being strings you have a loosely coupled Law of Demeter architecture which is easy to grow without increasing the complexity of the code base. I don't see the connection between cause and effect, unless this is saying "since everything is in the global state there is no coupling". Seems odd.

rattray 12y ago

This looks great. The docs really are terrific, too. Personally, I've been playing around with Bacon.js (or RxJS) instead of the Flux dispatcher. Using `Bacon.update` in conjunction with Facebook's Immutable.js seems really promising. The outcome is a far more functional approach. A quick and dirty example: https://gist.github.com/rattrayalex/dee40d86813bcaa9de80 https://gist.github.com/rattrayalex/dee40d86813bcaa9de80

RobertKerans 12y ago
Thanks for posting that, I've just been trying to get something similar to work using Bacon, and was looking for some examples of how to approach it.
colinramsay 12y ago
It took me a second for this to click but it looks fantastic. It'd be good to follow this up with a larger example - what are the issues you foresee?
- mjohn 12y ago
  I recently used React + Bacon + Immutable in a small project and I haven't come across any issues yet. I haven't seen any larger-scale examples yet, but this blog post[0] was interesting and has links at the bottom to implementations of todomvc and the flux-chat example. [0] http://blog.hertzen.com/post/102991359167/flux-inspired-reactive-data-flow-using-react-and http://blog.hertzen.com/post/102991359167/flux-inspired-reac...
  - rattray 12y ago
    That post's code provided inspiration for this! Though I found their examples a bit over-engineered for my taste...
- rattray 12y ago
  Hopefully you'll see a blog post from me on this in the coming weeks =) I'm a little worried about finding a good answer to the Flux Dispatcher's elegant `waitFor`, but I have a few ideas that I think could handle that well. I'm also worried about "stream spaghetti", especially having streams defined outside of a central `Actions.js`. I'm not yet sure how to elegantly handle server-syncing, though again, I have a few ideas (and Marty seems to provide some too). Lastly, I don't know the performance characteristics of Bacon or RxJS.
computmaxer 12y ago
Have you considered omniscient with Immutable.js? https://www.npmjs.com/package/omniscient https://www.npmjs.com/package/omniscient
- Touche 12y ago
  Last time I looked the combination of all of those frameworks is quite large (like 400k+ IIRC).
- rattray 12y ago
  It was the inspiration for my current setup, actually! Ultimately, pure-Bacon seems more functional, and I wanted to use something where all the "primitives" (Immutable, Bacon, etc) can be used directly, and are extremely well-supported. I may add a few abstractions (eg; a basic Mixin for event-binding, along the lines of [0]), but would prefer not to have a framework that "does too much" or has much magic, at least until it's very widely-used. [0] https://www.npmjs.com/package/fluxbone https://www.npmjs.com/package/fluxbone
dugmartin 12y ago
Interesting use of a bus for each action. I'm curious why you used @setProps() instead of just storing the person object in the component state? Modifying props seems a like non "Reactish".
- rattray 12y ago
  Actually, I think you've changed my mind on this. The reason is that I'm coming from a React/Backbone background (see [0]), where the Backbone Model was passed in as a prop, and then also listened-to within the component. So in that context it would make more sense for it to be `props` instead of `state`. In this case, you can't really pass the person object in as props and then listen to it for changes from within the component, since the object is different from the stream "emitting" it. When the emitter and the object are different things, it makes sense that the emitter comes from `props` (or is directly `require()`'d, which may be an anti-pattern?) and the object is set in `state`. [0] http://www.toptal.com/front-end/simple-data-flow-in-react-applications-using-flux-and-backbone http://www.toptal.com/front-end/simple-data-flow-in-react-ap...

peterjmag 12y ago

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 https://github.com/spoike/refluxjs [2] https://reactjsnews.com/the-state-of-flux/ https://reactjsnews.com/the-state-of-flux/

mjohn 12y ago
I really like Reflux as well. In a recent project I used Bacon.js[1] to create my own implementation that ended up looking similar to Reflux. The project involved asynchronous requests triggered by the actions, and transforming & aggregating the returned data. Compared to Reflux, Bacon made it very easy to do this by composing small functions that are applied sequentially to a stream of actions. [1] https://baconjs.github.io/ https://baconjs.github.io/
bsimpson 12y ago
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.
- kylemathews 12y ago
  I've been using a "FilteredConnect" mixin that I wrote that's solved the "CurrentThing" store problem nicely.
  - bsimpson 12y ago
    Interesting. Link?
    - kylemathews 12y ago
      Still private — need to create a pull request against Reflux.

colinramsay 12y ago

I'm scanning the documentation for this now and the "state sources" concept looks useful. Stores seem to be a bit cleverer than in other Flux implementations too. The fact it's got a Chrome extension and what appears to be comprehensive documentation bodes well. I'm currently using reflux because I like its simplicity (no dispatcher and no action creators) but Marty has definitely piqued my interest. Edit: Question for the author. Any thoughts on isomorphic apps with Marty? Edit2: Answering my own question: https://github.com/jhollingworth/marty/issues/13 https://github.com/jhollingworth/marty/issues/13

glifchits 12y ago
General impression is the same. I'm using Reflux and quite happy with it, but this does seem pretty smart. Having built in rollback of actions is nice, and having the versatility of where-queries to invoke action handlers is interesting. Not sure if its worth the switch, there aren't really pain points to be solved here... but my next React project might use this.
jfhollingworth 12y ago
Isomorphic apps are the next big challenge. Right now the biggest blocker is that everything's a singleton. I'm working on an internal container which should hopefully mean existing apps can be made isomoprhic without a change to the API
- btown 12y ago
  I've found that contexts are a good way to handle this - they're basically invisible props that get implicitly passed down the component tree, and mixins can whitelist which parts of the context they want to be able to use. They're undocumented, but they're used quite widely in React, so I doubt they're going anywhere. You can have a top-level component instantiate new dispatchers and stores and expose them as i.e. "this.context.userStore", "this.context.dispatcher" to mixins and component code. And this can be done concurrently in the same Node process without needing VMs/sandboxing. Your state mixin API might need to change a bit, but it can be substantially the same: var UserState = Marty.createStateMixin({ listenTo: "UserStore", getState: function (UserStore) { return { users: UserStore.getAll() }; } }); A reference: https://www.tildedave.com/2014/11/15/introduction-to-contexts-in-react-js.html https://www.tildedave.com/2014/11/15/introduction-to-context... Fluxxor, FYI, bundles all of this in context.flux: https://github.com/BinaryMuse/fluxxor/blob/master/lib/flux_mixin.js https://github.com/BinaryMuse/fluxxor/blob/master/lib/flux_m...

oliverwoodings 12y ago

I've contributed to this project on the state sources. For me Marty is the best Flux implementation available right now. When reviewing other frameworks I found them to be either too restrictive by imposing non-flux limitations or the complete opposite by not implementing the flux principles well enough.

dengar007 12y ago

This looks fantastic. Great work on the documentation too!

agilebyte 12y ago

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?

dalacv 12y ago
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.
- egeozcan 12y ago
  I try to do my best to follow the trends in JavaScript development and do mostly develop with JavaScript and even I can't keep up with the new terminology these days. When looking at marty.js documentation, I was constantly trying to map the new concepts to the ones I already know about.
- elwell 12y ago
  Would make sense given Marty is a reference to Marty McFly from Back to the Future; having to do with state management through time and, of course, Flux capacitors.
  - bronson 12y ago
    And it wouldn't be the first time: https://github.com/kenwheeler/mcfly https://github.com/kenwheeler/mcfly

prottmann 12y ago

Can't see a difference between marty and fluxxor. The examples look for me the same, except some additional functions to declare things.

oliverwoodings 12y ago
A first look at the examples for both projects would give you that impression. Some areas that Marty differs in: - State sources: http://martyjs.org/api/state-sources/index.html http://martyjs.org/api/state-sources/index.html - Contants are handled more intelligently: http://martyjs.org/api/constants/index.html http://martyjs.org/api/constants/index.html - Dev tools: http://martyjs.org/devtools/ http://martyjs.org/devtools/
jfhollingworth 12y ago
Author here. I found that no other Flux implementation really helped with fetching data in a Fluxy way. There tended to be a lot of boiler plate code for binding stores to components. Furthermore, there was a lack of tooling for debugging. Marty helps combat these issues by introducing a number of new things: - Fetch API for fetching data asynchronously without callbacks http://martyjs.org/guides/stores/fetching-data.html http://martyjs.org/guides/stores/fetching-data.html - State Mixins for binding stores to views http://martyjs.org/api/state-mixin/ http://martyjs.org/api/state-mixin/ - State sources for syncing state from heterogeneous sources http://martyjs.org/guides/state-sources/index.html http://martyjs.org/guides/state-sources/index.html - Chrome Developer extension (beta) for visualising the data flow and state of stores http://martyjs.org/devtools/ http://martyjs.org/devtools/
- prottmann 12y ago
  Thanks, i will have a closer look. The integrated data fetching and data flow extension sounds interesting, at the moment i use superagent with the mentioned callbacks and events to visualize (it is not comfortable).
- bsimpson 12y ago
  Like many others, I've been using Reflux because it seems to be the easiest to understand and to work with by reducing the surface area of concepts you need to understand to just: 1) actions 2) stores. In Reflux, a store is effectively just a variable you want your component(s) to be able to access and an action is a function that tells the store what to change about its state. For instance, I might have a CurrentUser store that tracks who the current user is and notifies my Profile component when that changes. I might also have a switchUser action that tells CurrentUser to change its state to user #30. That's all you need to understand to use Reflux. It's certainly interesting to have data fetching baked into Marty, but it also introduces so many concepts. I think it'd be really helpful for people coming from other libraries if you had a big glossary that says what each thing is and why you felt a need to include it. What's a Marty constant and why is it different than an action creator? What purpose does the dispatcher serve? etc. You'd have a better time recruiting and training new users with a diagram that shows how all these concepts fit together and why you need so many of them.

hakanderyal 12y ago

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 stores (so undo/redo is available without much work), loading data into stores from different sources etc. I believe, in the following months, a de-facto flux framework will emerge, and marty looks so close to being that framework. A few tips to fellow developers want to try react and/or flux: - React is just the view part. Integrating it with other frameworks is easy, and integrating other js libs with react is also easy. - OTOH, if you want to build a whole complex app with react, use something like flux with it, since there isn't a flexible way to modify the app state from child components with react. - Immutable data structures really goes well with react + flux. I haven't been able to get the immutability/functional style before, and react + flux really helped with that. Thanks again for the great tools.

eric_bullington 12y ago
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 statement is true as long as the framework in question doesn't touch the DOM (e.g., using Backbone models). But if you try to integrate React with any JS library or framework that mutates the DOM, you should be aware that this will interfere with React's DOM "accounting" and potentially cause lots of problems. There are certainly ways around this (look into the lesser-used React life cycles), but it's much easier to stick within the React ecosystem for any libraries that manipulate the DOM, or build your DOM manipulations from scratch (easy to do with React). Already, there's a fairly feature complete React Bootstrap library [2]. I've started work on a React charting library, using d3 for path calculations and other utilities (and temporarily for chart axes generation, but library users shouldn't have to worry about any DOM issues) [3]. And I'm sure there are a thousand and one other React view-level component libraries I'm not familiar with, most of which are likely available via NPM. But I agree that React and the other virtual DOM libraries and frameworks (Ractive, Mercury, Om, etc.) are the next generation approach for client-side views. They not only make DOM manipulations much snappier, but they also make them much easier for the developer. 1. https://github.com/dustingetz/react-cursor https://github.com/dustingetz/react-cursor 2. https://github.com/react-bootstrap/react-bootstrap https://github.com/react-bootstrap/react-bootstrap 3. https://github.com/esbullington/react-d3 https://github.com/esbullington/react-d3

knivets 12y ago

Make for building — interesting.

picardo 12y ago

Nice documentation. But I don't see anything groundbreaking here. The whole rationale for Flux is to unidirectional state flow, and it does that quite well. A lot of library creators have focused on the tiny quibbles with "ease of use" around stores and constants –– "state management" is a good euphemism for this need –– but that's not really a bottleneck for me. I can manage my constants manually with Flux, and add listeners myself. If I need to indicate a dependency between to stores, I can use a waitFor in the switch/case block. It's that simple. Why should I learn a bunch of abstractions that make only an incremental difference? My only pet peeve with Flux is that it does not let me dispatch from within an ongoing dispatch, which is not a huge deal yet because you can just defer the callback to the next event loop, but it's not allowing me to pipeline actions as I thought it should. I have to wait for the stack to empty out before I can dispatch a new action, which sucks. Also, there is no indication as to when a dispatch is over, so I am deferring dispatches by instinct –– or wrapping them in a promise might be the same thing.

jfhollingworth 12y ago
Hey, author here. This is a repeat of my answer below but it's right down the bottom so might be missed: I found that no other Flux implementation really helped with fetching data in a Fluxy way. There tended to be a lot of boiler plate code for binding stores to components. Furthermore, there was a lack of tooling for debugging. Marty helps combat these issues by introducing a number of new things: - Fetch API for fetching data asynchronously without callbacks http://martyjs.org/guides/stores/fetching-data.html http://martyjs.org/guides/stores/fetching-data.html - State Mixins for binding stores to views http://martyjs.org/api/state-mixin/ http://martyjs.org/api/state-mixin/ - State sources for syncing state from heterogeneous sources http://martyjs.org/guides/state-sources/index.html http://martyjs.org/guides/state-sources/index.html - Chrome Developer extension (beta) for visualising the data flow and state of stores http://martyjs.org/devtools/ http://martyjs.org/devtools/
- picardo 12y ago
  You're right about the boilerplate. I use a wrapper around React.createClass to take care of that. Kinda similar to Marty.createStateMixin, but it's just a component factory. The Chrome plugin looks very nice, but you can do the same thing with console.log() outputs in your store. It's a nice to have, but not filling a need for me.

chadscira 12y ago

Does marty.js support the concept of an app context? The only implementation i know of is Yahoo's fluxible (https://github.com/yahoo/fluxible https://github.com/yahoo/fluxible). This is mainly useful when you're trying to render your flux app on the server.

jfhollingworth 12y ago
Not right now but isomorphisim is the next big feature I'm going to be working on
- chadscira 12y ago
  Awesome, i have been in search for a good solution for isomorphic flux implementations.

jordanlev 12y ago

This looks really neat, and the documentation does seem nice. What I would absolutely love (and I'm sure many others as well) is a tutorial that shows how to build a very simple app from scratch... like a list of records and then click on a record to bring up an edit form (something super basic, but a tad more complex than TodoMVC). The problem I have is wrapping my head around how I put all the pieces together. Thanks!

corford 12y ago

Slightly OT but has anyone tried Marionette + React as a combo? Would be very interested to hear how smoothly (or not) it went.

lrichardson 12y ago

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 https://github.com/kjda/ReactFlux It's very similar, but I think I like how Actions and subscriptions to actions are handled with it better.

UberMouse 12y ago
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.
- lrichardson 12y ago
  Funny... I actually created some store mixins to do the exact same thing. 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 https://github.com/kjda/ReactFlux/issues/4

rpwverheij 12y ago

I'm using react quite a lot, but with my own API / storage solutions. So far I'm not really familiar with flux, and also with this, just quickly looking at it, I don't understand if/why I would need it. I can't really wrap my head around what exactly all this allows me to do and can't bring up the effort to read all the docs. I think I'll read more about flux first at some point, and if I'll ever want to use that, come back and check Marty :) Happy to see active react development though

zachallaun 12y ago
If you haven't seen it yet, they have a nice Flux write-up in the docs: http://martyjs.org/guides/flux/index.html http://martyjs.org/guides/flux/index.html. (I apologize if you've already seen it, though.)
jasim 12y ago
In your typical React component, you'll keep state in the parent, and pass them down as props to the children's subtrees. You also have to pass down handlers (`handleNameChange` for example) along with the props so that the child components can change the state. These handlers travel back to the parent, modify the state there, which triggers a re-render, and that travels from the parent down all the way to all the children again. This works for most use cases. This however forces you to keep all your model logic (computation, transformation, validation and server-communication) in the parent view component. So you'll extract a Model out of it, in which you keep all this data and logic. All the handler methods in the parent component would then call the mutation methods in this model instead of changing the component state directly. But now you need to ensure that the component state is consistent with the model state, for which you hook into the Model's onChange callback in the component's `componentDidMount` method. This means whenever the Model mutates, the component state changes accordingly. For example, if you have a `setPageTitle` method in the Store (that's what we call our Models in Flux), the store would mutate the value when `setPageTitle` is invoked, and call its own `emitChange` method, which triggers the `onChange` callback on the component which was registered during its `componentDidMount`. See: https://github.com/facebook/flux/blob/master/examples/flux-chat/js/components/ThreadSection.react.js#L34 https://github.com/facebook/flux/blob/master/examples/flux-c.... You use EventEmitter (I prefer EventEmitter3) on the Store to make it an observable. See: https://github.com/facebook/flux/blob/master/examples/flux-chat/js/stores/ThreadStore.js#L56 https://github.com/facebook/flux/blob/master/examples/flux-c.... The first step in Flux is this: a simple View-Model separation using an EventEmitter store. Apart from the View-Model separation, this lets you share global state between multiple components. (Global state is bad for programmers, but the real world doesn't care. There are instances where you need to share the same data between multiple components and have them all update automatically) In the ThreadStore example I linked to above, the `emitChange` method is called only through the Dispatcher at the bottom. This is the next step: we do not let any component modify the store values directly. Everything is channeled through a uni-directional dispatcher. The reason to do this is to avoid one Store talking to another Store talking to another, and each of these causing cascading state changes in the components that observe them. So instead of having multiple intertwined paths to the Store, you force the entire application to go through a single-channel dispatcher that process each Action in sequence. The Actions are simply constants that are available globally to invoke specific behaviour across one or many stores. Each Store watches out for the Actions (a constant pushed into its mesage bus) they are interested in, and calls the appropriate method in its body. You push the Actions into the dispatcher, who is responsible for sending it to each Store. The dispatcher uses the same EventEmitter observable pattern to bind each Store to the actions they are interested in. Written in a hurry, but I hope it helps. The flux-chat repo (https://github.com/facebook/flux/blob/master/examples/flux-chat https://github.com/facebook/flux/blob/master/examples/flux-c...) is a great place to understand the entire pattern.

kuni-toko-tachi 12y ago

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.

grandalf 12y ago
A few questions: - What is the equivalent of the global action bus in Flux? - How do you handle consuming data from multiple rest endpoints? - Suppose you want to restructure the components in the app into a different hierarchy, how much refactoring is involved? - Is there any open source example code of an app built this way that is more complex than a simple todo or simple async example? (I think the biggest challenge with these kinds of apps comes at that next tier of complexity... it's trivial to do a clean TODO implementation that doesn't do anything with server data in nearly any framework).
- hakanderyal 12y ago
  In flux, all the data are stored in stores. When a component needs data, it subscribes to the relevant stores, and updates itself on data changes. When you want to mutate the data, you call an action, which in turns mutate the data in the store. Since the components are subscribed to stores, they get the new data automatically. Stores subscribe to a central dispatcher, listening to all actions. When an action fires, they look the action's data, and mutate their data if it is relevant to them. The data flow is action-> dispatcher-> store -> component -> action. When you want to get data from a rest endpoint, you fire an action from the component. The action fetches the data, and pushes it to dispatcher.
  - grandalf 12y ago
    I know how this works in Flux, but wondering how it works using the approach w cursors.
tel 12y ago
Obligatory Bacon.js and RxJS are not FRP but merely RP statement.

goatslacker 12y ago

Congrats, the site looks really nice and the devtools feature is great!

daveidol 12y ago

One thing I would love to see some guidance on with Flux (and potentially with the patterns expressed in Marty.js) is how to handle the use case of Stores for a collection of items as well as a single item. Right now, if I create a Store for a collection of Users and I want to be able to mutate these User objects then I create actions for each CRUD mutation and then plumb that change through to the in-memory object inside my collection as well as persist the change to my server. But as soon as I click on a specific User and load up a new page for that User, for example, then I need to create an all new Store just for a single User, which has all of the same mutations/actions available to it as the previously-mentioned collection Store (except now I don't need to pass the ID to every action payload). The best approach I've seen on this topic is in this example's Readme: https://github.com/gaearon/flux-react-router-example https://github.com/gaearon/flux-react-router-example Does this approach make sense/jive with the Marty.js way of handling Stores, State Sources, etc?

hakanderyal 12y ago
The method that you linked is the one I use currently. Another way is to use a nested immutable data structure (something like immutable.js[1], react-cursor[2]), use only one store, and make all changes on this data structure and pass accordingly. Even if you don't use immutable.js, I strongly suggest to use immutability with react update[3] or equivalent. Things get way easier that way. [1]: https://github.com/facebook/immutable-js https://github.com/facebook/immutable-js [2]: https://github.com/dustingetz/react-cursor https://github.com/dustingetz/react-cursor [3]: https://facebook.github.io/react/docs/update.html https://facebook.github.io/react/docs/update.html
- daveidol 12y ago
  Thanks for the suggestions. I've looked at immutable data structure libs some, but I haven't seen any real comprehensive examples showing the behavior you describe within the Flux pattern. Do you happen to know of any such examples? I ask because the examples I see for react-cursor, etc typically show data being mutated directly inside the React component without using Actions/Stores/etc. Going this route means we lose the advantages such as a unidirectional data flow & the ability to centralize logic for interacting with a Store around well-defined Actions. So if we did merge the Flux idea with Cursors, I assume we would keep a single Cursor as the underlying state inside a Store, and then use the traditional Action/ActionCreator model to allow React components/server updates to mutate this Store? What is the big win here then vs. traditional (non-immutable) Stores (other than performance gains by using === in shouldComponentUpdate)? It seems to me you would still have to make a separate Store for editing a single item vs editing a collection.

STRML 12y ago

This seems very similar to Fluxxor, but solves some of the pain points. Stores need to be extendable, and the Mixin concept (as used in React Elements) are a very useful way to do it. In this way, one can easily implement Marty's "State Sources" concept. I released a fork of Fluxxor a while ago with Mixin support [1] but it is unlikely to make it until 2.0. The other nice parts to my eyes are: State Mixins - sort of a hybrid between Fluxxor's StoreWatchMixin and Fluxxor-autobind [2] Constants - This is a new one, I like it. Will have to play with it to see if it truly solves any problems; I've found that when I need to know what actions are available, I scan my actions files, simple as that. Marty seems a little more "batteries included" than the other Flux implementations on the scene. This is a good thing, so long as it is easy to extend. Unfortunately I still don't see Mixins in Marty Stores either. In my opinion they are required for non-trivial apps. 1. https://github.com/STRML/fluxxor/tree/storeMixins https://github.com/STRML/fluxxor/tree/storeMixins 2. https://github.com/STRML/fluxxor-autobind https://github.com/STRML/fluxxor-autobind

jfhollingworth 12y ago
Author here: Marty stores do have mixins, think I forgot to add them to the docs
- STRML 12y ago
  Great! That's a big plus for me.

thomasfl 12y ago

Even if HN readers are getting tired of all the new "Javascript librairie de jour", it's really exciting to see how new techniques are refined and improved in a fast tempo. Keep them libraries coming!

joesb 12y ago

I really want to use React in my next application, but I'm lost on how to do visual things like animation (like a carousel), drag-drop, typeahead. Do you have any suggestion on the best practice on doing those heavy DOM stuff in React? I know I can use jQuery for that, but it feels wrong to me. Also how do you handle integrating React with command based JS library, where your only interface to it is to call mutating functions, such that you cannot blindly rerender the whole things. Suggestions on these two issues would help me greatly.

joesb 12y ago

I hope all the virtual-DOM based library comes to concensus with one based virtual-DOM library, or that it becomes part of the browser standard. I don't mean the whole React library, I mean just "this a the DOM before, here's the change, now patch it" part. More and more framework and UI library are going to be built around vritual-DOM concept. I don't want integration nightmare of UI-libraries working only on some React-like library.