[hakanderyal]

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]

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

2. https://github.com/react-bootstrap/react-bootstrap

3. https://github.com/esbullington/react-d3

[Confiks]

> (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 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:

https://gist.github.com/confiks/745d27f7308db1935eb9

[albertoleal]

By the way, the hypothetical reflux store in your gist is basically this: https://github.com/omniscientjs/immstruct

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.

[eweise]

I discovered your react-d3 project last week and started using it a bit. Thanks a lot for making it.

[eric_bullington]

Thanks for your comment, much appreciated!

[Touche]

If you want a framework with immutability you should probably just use https://github.com/Raynos/mercury as it gets rid of React's unnecessary component state.

[kaonashi]

Gaa, another framework that's opinionated about the data structures it gets passed. No thanks.

[malandrew]

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 observ-varhash. Serialization and hydration works basically out of the box.

My reaction to the marty stuff is that it's trying to moved towards an architecture that mercury already has out of the box and that you don't have the unnecessary component state stuff the parent comment mentioned.

The component state stuff is probably my biggest gripe with the way react is architected.

[hakanderyal]

Haven't used mercury, but in react component state has it's uses. It's strongly recommended both in docs and mailing list that component state should only be used for ephemeral data, the data that losing is not a problem when the component unmounts.

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.

[kaonashi]

IMHO, that sounds like more of a concern for the data structures you're using, not the view layer.

I do appreciate you taking the time to lay out the advantages, and I was rather flippant.

[goatslacker]

Curiously, what about marty do you really like that makes it feel like a good de-facto framework?

[hakanderyal]

Well, de-facto may be a strong word for what I meant, as everybody has their own way of doing things.

For me, appealing side of react + flux for me is it's simplicity. Adhere to the few principles of them (one way data flow, no permanent state in components etc.), and you have a scalable architecture in your hands, with little to no magic on the data side.

Haven't used marty yet, and since I've already developed what marty offers on my own app already I don't plan on using it soon, but from what I read in the docs, it doesn't try to do too much, or make too many decisions on your behalf. It offers more structure than a barebones dispatcher, without getting in the way. And in my experience, that is a really efficient and scalable way of building complex apps.