search

reflux / refluxjs

A simple library for uni-directional dataflow application architecture with React extensions inspired by Flux
BSD 3-Clause "New" or "Revised" License
5.36k stars 330 forks source link

Looking to create a simple Manifesto #327

Closed squeedee closed 8 years ago

squeedee commented 9 years ago

Hey! Great library! But, it is a bit of a departure for me.

When I last did front end M/V separation I used RobotLegs in Actionscript. Even so, a lot of us (RobotLegs users) employed a habit of 'following the canon', or to put it another way, update state in response to user actions, and always have views follow the most 'canonical' state.

It's not much different from the flux model in that respect, however a lot of other MVC habits don't directly match up with Reflux. Additionally, some of my colleagues here at Pivotal Cloud Foundry have used MVC framework, often finding they end up with spaghetti despite the separation of modeling and views.

So I thought it was high time I documented the idioms of reflux. I've made an attempt, but I'm sure there is more to be said. I would really appreciate your feedback. Perhaps if this proves useful, it can ultimately be merged into your wiki/org?

Regards, Rasheed Abdul-Aziz

squeedee commented 9 years ago

There's particularily a dearth of information about using stores as Map-Reduce. I think the idea is to replace if-then-else type logic with 'when' - predicate requirements for further steps in reduction. I would love some more complex examples of code with map reduce logic intermingled with async events.

spoike commented 9 years ago

Did a quick read and it looks okay. :+1: Yes, facebook has since the beginning pushing out the notion of one MVC habit in particular, bidirectional data flows causes some of the spaghetti code issues most projects have. Specifically regarding derived data as they call it. You can read this in the flux docs about structure and dataflow, they suggest:

Flux Simple Diagram A unidirectional data flow is central to the Flux pattern, and the above diagram should be the primary mental model for the Flux programmer.

You can skip the parts about the dispatcher in that page, since it has been built in to the actions themselves as good old event emitters... and skip the part about action creators as reflux actions are just functions that pass parameters to it's event listeners (preferably stores, but you can also shortcut down to components too if you want).

Will have to review more later as I have no other priorities left other than to maintain reflux (currently taking care of my newborn premature baby).

LongLiveCHIEF commented 9 years ago

@squeedee this is very interesting, and helpful indeed. I've been thinking about this a lot lately, and think this would be a great addition in the help links section of the docs and guides, if we can get some real-world application of this manifesto.

I have the perfect project, and would like to discuss your thoughts and some differences I might suggest. Are you signed up for the #reflux channel on Reactiflux Slack group? ( Sign up here for an account.). It's where I spend most of my time, s/n is @ngdchief.

(or lmk if you're using gitter instead).

spoike commented 9 years ago

We'll be working on the reflux site soon, so I'll revisit this at some point.

devinivy commented 8 years ago

It would be great if this conversation could continue over at our new repo for general discussion (https://github.com/reflux/discuss). @squeedee when we make the site, we'll be sure to revisit this. Thanks for pulling these thoughts together!