Congrats, the site looks really nice and the devtools feature is great!
Marty.js – A JavaScript library for state management in React applications
71–80 of 95 posts
Re: Marty.js – A JavaScript library for state management in React applications
#72One 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
Does this approach make sense/jive with the Marty.js way of handling Stores, State Sources, etc?
Re: Marty.js – A JavaScript library for state management in React applications
#73Earlier quoted context omitted.
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.
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.
And it wouldn't be the first time: https://github.com/kenwheeler/mcfly
Re: Marty.js – A JavaScript library for state management in React applications
#74Nice 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…
Curiously, what about marty do you really like that makes it feel like a good de-facto framework?
Re: Marty.js – A JavaScript library for state management in React applications
#75This 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
Have you considered omniscient with Immutable.js? https://www.npmjs.com/package/omniscient
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.
Re: Marty.js – A JavaScript library for state management in React applications
#76This 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
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".
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-ap...
Re: Marty.js – A JavaScript library for state management in React applications
#77This 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
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?
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.
Re: Marty.js – A JavaScript library for state management in React applications
#78Earlier quoted context omitted.
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?
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-reac...
That post's code provided inspiration for this! Though I found their examples a bit over-engineered for my taste...
Re: Marty.js – A JavaScript library for state management in React applications
#79Nice 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…
Curiously, what about marty do you really like that makes it feel like a good de-facto framework?
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.
Re: Marty.js – A JavaScript library for state management in React applications
#80Does marty.js support the concept of an app context? The only implementation i know of is Yahoo's fluxible ( https://github.com/yahoo/fluxible ). This is mainly useful when you're trying to render your flux app on the server.
Not right now but isomorphisim is the next big feature I'm going to be working on
Awesome, i have been in search for a good solution for isomorphic flux implementations.