Feedback I receive around suggest that reflux needs to be more friendly for isomorphic projects, i.e. same actions and stores can be run both client-side and server-side.

The goal with this issue is how can we achieve this in reflux and still keep a simple API?

Suggestions and PR's are welcome.

Hello,

I'm experiencing an issue where if I update a textarea's value through the Action → Store → View flow, with the cursor not at the end, the cursor will jump to the end. The same doesn't happen if I use state internally in the component to keep track of the current value, like in this example.

Does this by an off chance have to do something with this?

Action and store callbacks are not executed in a single synchronous iteration

The code is something like this:

render: function() {
  return (
    <textarea
      value={this.props.value}
      onChange={this.handleChange}
    />
  );
},

handleChange: function(ev) {
  Actions.updateMessage(ev.target.value);
}

Also noticed this one, https://github.com/facebook/react/issues/1698

Added a few API elements to better make use of what's going on with Reflux.GlobalState

Main two additions:

Reflux.getGlobalState and Reflux.setGlobalState methods. Former allows a deep clone of the Reflux.GlobalState which won't continue to mutate (so you can easily store snapshots of the global state) and the latter allows you to set the global state at any point (including with partial global state objects that will only override the stores/properties represented). This basically allows an API for state based time travel.

Also added is the Reflux.initializeGlobalStore method. With expanded global state ability comes more usefulness in working with ES6 stores both in and outside of components. This allows instantiation of a proper singleton instance of a store and setting it up for tracking by the global state without any need to attach to a component.

Tests, documentation, and a lot of code commenting was also added.

This adds a convenient listenables prop to createStore, which lets you easily listen to all listenables in an object (read: the return value from createActions).

Here's the example added to the README. If you've previously done this:

var actions = Reflux.createActions(["fireBall","magicMissile"]);

...then instead of doing this:

var Store = Reflux.createStore({
    init: function() {
        this.listenTo(actions.fireBall,this.fireBall);
        this.listenTo(actions.magicMissile,this.magicMissile);
    },
    fireBall: function(){
        // whoooosh!
    },
    magicMissile: function(){
        // bzzzzapp!
    }
});

...you can now do this:

var Store = Reflux.createStore({
    listenables: actions,
    fireBall: function(){
        // whoooosh!
    },
    magicMissile: function(){
        // bzzzzapp!
    }
});

To enable this to be used with an object of stores too (hence the agnostic name listenables), I added support for getDefaultData in the listenable. That data is sent to the listening callback, or a this.<callbackname>Default if that exists.

It's entirely possible that this is an architecture question, and not a functionality question. I'm coming from a backbone background, where we can namespace events coming out of a model: this.trigger('namespace:eventName', args);

That namespace allows me to have various parts of an app share a model, but only take an action if they are listening for that particular eventName and namespace. Is there something like this in Reflux, or am I missing something in the inherent architecture here? All of the examples have a store firing a trigger event, with the entirety of its data.

For example, if I have an AppStore, and it hold the states for a few things (modal visibility, which menu is open). My modal component only needs to care about whether there's some modal data, my menus only which menu is active, etc. Thanks.

While browserify compiles this library fine, when I try to use it, it get this in the console:

Uncaught Error: Cannot find module '../src'

and when I look at the browserify generated code, I see stuff like this:

},{"../src":undefined,"./utils":174}],169:[function(require,module,exports){

Why is this not working (using version 0.1.15)?

I was profiling our application and it seems like there's a potential memory leak in Reflux - the Keep object holds references to all the created Stores and Actions (createdStores, createdActions). I don't think there's any official way to remove these references, which causes a leak if your stores aren't singletons.

I know that as per the official Flux rules, stores should be singletons, but this rule is not exactly written in stone. Would it be possible to provide official API to release stores and actions completely? If not, I think it should at least be mentioned in the docs.

Edit by @BryanGrezeszak: I'm putting this at the top since this page gets a lot of google traffic. Reflux does now support and embrace ES6 classes in React. You may check the documentation for more info.

It would have been fantastic if I could do:

class MyStore extends Reflux.Store { init(){ ... } }

This would allow editors/jshint/flow to more easily do code checks, like checking method names, than what is possible with a dynamic object that Reflux.createClass gives.

Any chance for this in the near future? :)

Async actions

There has been some discussion on asynchronous actions (https://github.com/spoike/refluxjs/issues/57, https://github.com/spoike/refluxjs/pull/103) and where to best handle them.

The consensus seems to be that triggered execution is best kept outside of the stores, and I personally agree. In my opinion, the store shouldn't worry about how actions are run, focusing merely on their results. It also makes testing easier, as a few folks have noted.

The pattern proposed in the update on v0.1.8 links the execution of asynchronous code to the preEmit hook of an action, after which it triggers events on "Completed" and "Failed" actions, like so:

var ProductAPI = require('./ProductAPI');  
// contains `load` method that returns a promise

var ProductActions = Reflux.createActions({  
    'load',         // initiates the async load
    'loadComplete', // when the load is complete
    'loadError'     // when the load has failed
});

// Hook up the API call in the load action's preEmit
ProductActions.load.preEmit = function () {  
     // Perform the API call, get a promise
     ProductAPI.load()
          .then(ProductActions.loadComplete)
          .catch(ProductActions.loadError);
};

Issues with preEmit

While this is definitely the cleanest way I've seen, some things still bothered me about it:

• There is no semantic link between the "load" and "loadComplete" / "loadError" events. Nothing in the interface reflects the fact that they are related.
• Putting an API call, or some other asynchronous code, in the preEmit hook seems hacky to me. Others have expressed similar sentiments (https://github.com/spoike/refluxjs/issues/57).
• I think it's overly verbose. There's still some unnecessary boilerplate here, and for every async event (of which there can be loads) we have to now manually define 3 separate actions. If at some point we want to add a "Canceled" action as well for all our calls, we'll be doing busy-work for a while.

Proposal: Child actions

It appeared to me that if we could define child actions (attached to a parent action), we could design a much nicer interface. This commit is an implementation of that idea. The general interface looks as such:

// ProductActions.js

var ProductAPI = require('./ProductAPI');  
// contains `load` method that returns a promise

// Define action with child actions
var ProductActions = Reflux.createActions({  
    'load': {children: ['completed','failed']}
});

// And here is how you would hook it up to a promise
ProductActions.load.listen( function() {
    // Bind listener context to action by default
    ProductAPI.load()
        .then(this.completed)
        .catch(this.failed);
});

// ProductStore.js

var ProductActions = require('./ProductActions');

// This is how you would listen for a completed load
ProductActions.load.completed.listen(function(result) {
    // do something with result
});

// listenToMany (and ListenerMixin) will still work intuitively
var Store = Reflux.createStore({
    init: function() {
        this.listenToMany(ProductActions);
    },
    onLoad: function(){
        // product load started
    },
    onLoadCompleted: function(product){
        // product load completed
    }
});

Common-case helpers

I figured it would make sense as well to provide some helper methods and options to make the 80% case easier. This works as such:

// Define actions with async option to auto-create
// 'completed' and 'failed' child events
var ProductActions = Reflux.createActions({  
    'load': {async: true}
});

// Hook up standard async child functors
// to a promise easily:
ProductActions.load.listen( function() {
    // Have the action attach callbacks to the promise
    // and pass on data to "complete" and "failed" actions
    ProductActions.load.promise(ProductAPI.load());
});

// Or even easier for the 80% case, a method that
// hooks ups callbacks to a returned promise directly
ProductActions.load.listenAndPromise( function() {
    return ProductAPI.load();
});

Alternative uses

For custom cases, you could create alternative children events:

var ImageAPI = require('./ImageAPI');

// If we need custom child actions, we could do so:
var ImageActions = Reflux.createActions({
    'pictureUpload': {children: ['progressed','completed']}
});

// Hook things up to a non-promise-based API
ImageActions.pictureUpload.listen(function(){
    ImageAPI.upload({
        onProgress: this.progressed,
        onSuccess: this.completed
    });
});

Notes

Note, while createActions now operates on an associative Object, the interface remains backwards-compatible and accepts Arrays as well.

This has cleaned up my action definitions quite a bit. Curious to hear your critical thoughts / feedback! Thanks!

I have an async action to fetch a Thing from API.

I also have an async action to POST a new Thing to the API.

The natural payload for the corresponding triggers in the ThingStore is the Thing.

The problem arises when a component asks for a Thing, and while waiting for the async stuff, another component fires the action to POST a Thing.

Now at some point we're going to have two triggers fire, each with a Thing, and no way to know which is the result of which action. How is the component which POST'ed a Thing to know which is which? After all, it doesn't know how many Things to expect, maybe the store will actually be sending a fail trigger.

It would be great with an example on how to deal with asynchronous data sources along with optimistic updates in Reflux. Remote data is something everyone works with and something that Flux documents very poorly.

I suppose one way would be creating several events for each action (Todo.createItem, Todo.createItemSuccess and Todo.createItemFailure) and using the first to do optimistic updates.

It might be a good idea to either archive the repository, or add a note in README.md that the project is in fact dead. It would be very much apprieciated if you'd give some migration propositions too. I've seen https://github.com/mobxjs/mobx mentioned in few of opened issues - is this the recommended library to switch to?

I really like the idea of Reflux and would like to use it. Unfortunately, our project only uses functional components. From the documentation I didn't see a way to use Reflux with functional components. If there is a way, please let me know. Thanks! Chris

React 16.4.1 Reflux 6.4.1

On components that extend Reflux.Component, if I use

static getDerivedStateFromProps(props, state) {...}

without implementing componentWillMount() (which is now UNSAFE in React), the Reflux functionality in the component fails, and I get a console error:

In the screenshot, below the error, I printed this.componentWillMount from the component's render() method, attesting it comes from the Reflux.Component implementation.

In summary, due to implementing a now UNSAFE componentWillMount(), Reflux.Component cannot be used with the new static method getDerivedStateFromProps().

I have an action defined as

doSomething: { asyncResult: true}

in the code I have

doSomething("some params").then(..).catch(...)

This used to work in 0.2.x versions. After upgrade to 5.0.4 action invocation started to return undefined which naturally was throwing a JS exception.

Why is this no longer working? What is an alternative approach if this is not a bug?