acdlite / flummox Goto Github PK

First I have to say that this is a great library. I'm currently using it in one of my projects and stumbled upon some smaller issues.

1. Why do you "force" the user to return a String from a Store's serialize method? As far as I can see the whole state object is stringified anyway (https://github.com/acdlite/flummox/blob/master/src/Flux.js#L156). Let's say we have two Stores A and B, the result of flux.serialize() would look somewhat like this: JSON.stringify({ A: JSON.stringify(A.state), B: JSON.stringify(B.state) }) although those two inner stringifications (is that a word?!) are not necessary.
2. In case of deserialization the flux class currently tries to parse the serialized state and if this works without an error it calls the deserialize function of each class. But you don't pass the parsed JSON as a function parameter to those calls, but the serialized state (https://github.com/acdlite/flummox/blob/master/src/Flux.js#L180) which means that each Store has to call JSON.parse again. This could be easier ;) You could even do something like that let storeState = deserialize(state[key]); and pass only the state to each store that is relevant for it.

I have an action like this:

async loadMany() {
  let response;
  response = await Axios.get(`/api/robotz/`); // wrong URL to produce error 
  return List(response.data);
}

and a store connection line like this:

this.registerAsync(actionIds.loadMany, undefined, this.loadManyCompleted, this.loadManyFailed);

As promise rejects (API returns 404), this.loadManyFailed handler is called but I get a message Unhandled promise rejection. How can it be unhandled if handler is called?

If I wrap AJAX request in try/catch, error is gone, but I cannot reach this.loadManyFailed anymore.
As I understand, this fail handler is meant exactly for API errors (must not catch syntax errors, etc).
Where is my error?

Right now, serialization/deserialization only works if every single store implements serialize() / deserialize(), but it occurs to me that there's no reason why it shouldn't just skip over those stores that don't opt-in to this feature.

I'm making good progress towards my first fully functional prototype (trying to get SSR and HMR to work with React + Rails)

One thing I noticed during the creation of the Stores and Actions is that I am essentially recreating Backbone.sync (since I'm the pretty clasical CRUD case). What do you think of are the pros/cons of backing a Flummox Store with Backbone, i.e. yielding Collections or Models to the Components, and basically calling update, create, etc. from the Actions to avoid writing boilerplate to communicate with a CRUD REST API.

The immediate downside is obviously that the state of the store is technically mutable from outside via the yielded objects, but as long as we treat the yielded objects as read-only.

The upside I see is that we get Backbone's comprehensive Validation/Syncing power that maps in my experience pretty perfectly with CRUD.

I'm convinced that 99% of people who are interested in this project will already be using some sort of build step, so why offer a browser build?

Mainly so we know how big the library is. Right now I can't tell how much of the stuff loaded automatically by 6to5's self-contained mode is bloating the library. I would like to reduce it as much as possible.

Similar to #7, stop using Map type internally and just use objects. I would prefer to use Maps, but it's not huge deal, and this reduces the size of the library.

Right now constants are ES6 Symbols, because I thought that would be kewl, but they really should just be unique strings. That way, the entire state of the Flux instance can be represented as one big JSON string.

Is there a way to initialize data in the store via GET?

Here's a simple example of what I have to do now:

// Question Store
import {Store} from 'flummox';
import axios from 'axios';

export default class QuestionStore extends Store {
  constructor() {
    super();
    this.initialized = false;
    this.state = {
      questions: []
    };
  }
  getQuestions() {
    if(!this.initialized) {
      this.initialized = true;
      axios.get('/api/questions').then( (questions)=> {
        this.setState({questions: questions.data.response});
      });
    }
    return this.state.questions;
  }
}

// Consuming Component

import React from 'react';
import fluxMixin from 'flummox/mixin';

let Questions = React.createClass({
  mixins: [fluxMixin({
    questions(store) { return {questions: store.getQuestions()} }
  })],
  render() {
    return (
      <div>
        <h2>Questions</h2>
        <ul>
          {this.state.questions.map(function(q) {
            return <li key={q._id}>{q.question}</li>;
          })}
        </ul>
      </div>
    );
  }
});
export default Questions;

I can't run the GET in initialize because initialize get's called on page load, and I don't necessarily want to fetch the data until someone consumes the data. I know some people fetch the data via Actions, but I don't agree with that method (neither do some major flux players).

I suggest implementing an onFirstConsume function which gets called the first time a component gets injected into the DOM that depends on that store.

// Question Store
import {Store} from 'flummox';
import axios from 'axios';

export default class QuestionStore extends Store {
  constructor() {
    super();
    this.state = {
      questions: []
    };
  }
  onFirstConsume() {
    axios.get('/api/questions').then( (questions)=> {
      this.setState({questions: questions.data.response});
    });
  }
}

// Consuming Component

import React from 'react';
import fluxMixin from 'flummox/mixin';

let Questions = React.createClass({
  mixins: [fluxMixin(['questions'])],
  render() {
    return (
      <div>
        <h2>Questions</h2>
        <ul>
          {this.state.questions.map(function(q) {
            return <li key={q._id}>{q.question}</li>;
          })}
        </ul>
      </div>
    );
  }
});
export default Questions;

I was trying to create a Mixin for automatiacally subscribe/unsubsribe Stores and use it like this:

mixins: [StoreListener(this.props.getStore('my-store')],

I don't know why is not working, just getting a blank page with no error in cosole. Am I missing somenthing?

I ended up declaring inside the component which needs the mixin a method returning the used stores

getStores(){
    return {
      'my-store': this.props.flux.getStore('my-store')
    };
  },

and here the mixin:

'use strict';

var StoreListenerMixin = {
  getInitialState() {
      return this.getStateFromStores(this.props);
    },

    componentDidMount() {
      Object.keys(this.getStores()).forEach(key =>
        this.getStores()[key].addListener('change', this.handleStoresChanged)
      );
      this.setState(this.getStateFromStores(this.props));
    },

    componentWillUnmount() {
      Object.keys(this.getStores()).forEach(key =>
        this.getStores()[key].removeListener('change', this.handleStoresChanged)
      );
    },

    handleStoresChanged() {
      if (this.isMounted()) {
        this.setState(this.getStateFromStores(this.props));
      }
    }
};

module.exports = StoreListenerMixin;

Everything is working like a charm, just wondering if there is a smarter way for passing the interested store from the component to the mixin using this.props.flux

This is biggest missing feature that will bring it up to parity with other Flux libraries, I think. Should be pretty straightforward.

• Stores will have a default #serialize() and #deserialize that converts the entire state tree to JSON.
• Store subclasses can override #serialize() and #deserialize() if they're using, say, Immutable.js data structures.

For debugging purpose I tried to override the Flux#dispatch method, which is just a proxy call to the original dispatcher.
Here is the method in my Flux class

  dispatch(actionId, body, actionArgs) {
    console.log(actionId, body, actionArgs);
    super.dispatch.call(this, actionId, body, actionArgs);
  }

The problem is that the dispatchAsync method doesn't use the Flux#dispatch method but calls directly the original dispatcher one.

Is there a particular reason for that?
It would be great if everything that dispatches something, passed through the Flux#dispatch method. That way with a single console.log, we could see what's going on under the hood, with a great improvement of debugging capabilities for the whole lib.

What do you think?

We should make the Flux class an EventEmitter, with events on dispatch and error

This doesn't look right given the current file organization:

I'm missing one big part of how this all works: how do I dispatch an action from an event handler in a React component? I don't see that ReactMixin or ReactComponent have methods for doing this. I could get the flux instance from context and dispatch actions there, but that seems very messy.

Not exactly a flummox question, but would be great to discuss it somewhere.
It's up to @acdlite to close this as offtopic if he wants to keep issues clear (some people do).
Some people also prefer to discuss on Gitter. But those threads are temporal and non indexable.

Pagination is a good example to illustrate some thoughts. Everyone makes pagination so
we should have countless implementations, libraries and competition here, right?
Well... actually no.

When I've come from backend programming I just wanted to reimplement basic CRUD stuff. All that features I had before: filters, sorts, pagination. I expected to find multiple solutions, smart decisions for this. So naive! I started with Backbone. I read through a lot of Backbone books. I watched a couple of Backbone video courses. About zero enlightment. They didn't even approach the questions of state management. Load all your data, then do frontend-only filters, frontend-only sorts, frontend-only pagination. Backend versions were more scalable!

I switched to Ampersand. Same things there. Just improved Backbone, still bloody low-level.
Logicless templates. No, thanks. Then React. Better render, same widgets / todo apps.
Still no state management solutions.

I was just reading up on [email protected] and wanted to mention that cloneWithProps used by your FluxComponent will likely want to switch to cloneElement. cloneWithProps will be deprecated.

http://facebook.github.io/react/blog/2015/03/03/react-v0.13-rc2.html#react.cloneelement

It also looks like cloneElement will handle refs better than cloneWithProps did.

I need to check Store's state within an action for caching purpose.
In the action I need to check if the store already contains data, otherwise I'll call my ApiUtils.

Is there a way to have Store access within Actions?

I'm trying to get Flummox to work with Coffeescript, but seem not be able to get it to do so. First, I had to manually change require("react") to require("react/addons") to make cloneWithProps available, but even then I still get an error at https://github.com/facebook/react/blob/master/src/utils/cloneWithProps.js#L46 saying that child.props is undefined. The stack trace shows this happens in FlummoxComponent's wrapChild function. I'm trying to run this in the browser, fyi. Do you know why this happens?

If i have FluxMixin and i use a prop in the connectToStore thingie it does not fetch new data on prop change.

FluxMixin({
MyStore: function(store) { return { items: store.getItems(this.props.itemIds) }; }
})

if i pass new prop itemIds this.state.items does not get updated.

The answer is to use the Flux class to pass arguments to Actions and Store constructors.

Imagine the following scenario:

• I have a search form, when I submit it I pass the query string to another route which will use it to trigger an action to fetch data, populate a list in a store and display it in the page.
• I came back to the previous page, change the query and submit again.
• When I land to the list page, I see the previous search result because I haven't cleaned the store, and as soon the server call returns, I'll see new the new list.

I was wondering if you have a good pattern to suggest me in order to cleanup the stores.
Would be a good solution return a copy of the state in the store, and just earlier clean it up?
This would be a method in a Store

getDataFromStores() {
    //FIXME I don't know if this is the best approach to reset store status
    var ret = this.state.data;
    this.state.data = Immutable.List(); // restore the store
    return ret;
  }

It sound weird to me.
Either way, another action to clean everything up and restore the store at its initial state?

/// flux.js ==========================
export default class Flux extends Flummox {
  ...
}

// app.js ============================
let Flux = require("./flux.js");
let flux = new Flux();
...
window.router.run(function(Handler, state) {
  React.withContext(
    { flux }, () => React.render(<Handler />, document.body)
  );
});

// some-component.js  ================
...
  contextTypes: {
    flux: React.PropTypes.instanceOf(Flummox),
  },

  render() {
    console.log(this.context.flux); // Flux {dispatcher: Dispatcher...}
    console.log(this.context.flux instanceof Flummox); // true, right type
    return (
      <FluxComponent>
        <div>Root</div>
      </FluxComponent>
    );

Warning: Invalid context flux supplied to FluxComponent, expected instance of Flux. Check the render method of SomeComponent.

fluxMixin.js:62 Uncaught Error: fluxMixin: Could not find Flux instance. Ensure that your component has either this.context.flux or this.props.flux.

What's wrong? Also tried with <FluxComponent flux={this.context.flux}>. Same error.

While getting data from server, I'm used to fire an SUCCESS action if the call succeed, and a FAILURE action if it doesn't.
How can I deal with errors with flummox?

I'm trying to set up a reusable action class that extends the flummox action class for sharing basic CRUD functionality. I'd use that to extend my action creators from as I'll be making several similar stores that need to query only slightly different data. However, it appears that I'm unable to extend the Action class more than once.

Here's a snippet of my crud actions:

class CrudActions extends Actions {

  constructor(apiRoot) {
    super();
    this.apiRoot = apiRoot
  }

  create() { 
    return {};
  }

  async save(entity = {}) {
    let url = this.apiRoot;
    let method = 'post';
    if (entity.id) {
      url += `/${entity.id}`;
      method = 'put';
    }
    return request[method](url).send(entity).exec();
  }

  async getAll(opts = {}) {
    let url = this.apiRoot + (opts.id ? `/${opts.id}`:'');
    let {body} = await request.get(url).exec();
    return body;
  }

}

I don't actually add this on my Flux app
And here's an example class extending from that:

class PostActions extends CrudActions {

constructor() { 
    super('http://somedomain.com/api');
  }

  addToFavorites(post) {
    return post;
  }

}

Everything works as expected except when it comes to getting the actions from the Flux instance in my view:

// inside a view component

this.props.flux.getActionIds('posts')
// -> returns only the ids for the PostAction's own properties, ie. addToFavorites
// It does not include inherited property names.

I dug around in the Actions class and it appeared to be happening around here:

_getActionMethodNames(instance) {
    return Object.getOwnPropertyNames(this.constructor.prototype)
      .filter(name =>
        name !== 'constructor' &&
        typeof this[name] === 'function'
      );
  }

I was able to set the PostAction prototype to the CrudAction prototype, but then the problem happens in reverse:

// inside a view component

this.props.flux.getActionIds('posts')
// -> returns only the ids for CrudActions: save, create, getAll
// It does not include PostAction action ids

Now this may just be my own ignorance as I just started playing with the ES6 class syntax - but it seems I should be doing this as some sort of mixin anyhow. But how I can mixin a set of action creators and have those actions be recognized by the dispatcher when they aren't directly on my object's prototype?

There's also the possibility that I'm overcomplicating the setup and that there's a much simpler way to achieve this.

Also, great work on this project. I love it!

e.g. Store#handler()

Hi @acdlite (again) ;)

I'm sure I'm missing something but I can't get it to work. Can someone help me here?

This is my setup

class UserActions extends Actions {
  getUser() {
    return {
      name: 'John Doe',
      email: '[email protected]'
    }
  }
}

class UserStore extends Store {
  constructor(flux) {
    super()
    let userActions = flux.getActions('user')
    this.register(userActions.getUser, this.handleFetchedUser)

    this.state = {
      user: {name: '', email: ''}
    }
  }

  handleFetchedUser(user) {
    this.setState({
      user: user
    })
  }
}

class Dispatcher extends Flux {
  constructor() {
    super()
    this.createActions('user', UserActions)
    this.createStore('user', UserStore, this)
  }
}


describe('UserStore', () => {
  let store, dispatcher
  beforeEach(() => {
    dispatcher = new Dispatcher()
    store = new UserStore(dispatcher)
  })

  it('should update state with fetched user', () => {
    spyOn(store, 'handler').and.callThrough()
    spyOn(store, 'handleFetchedUser')
    let actions = dispatcher.getActions('user')
    FluxTestUtils.simulateAction(store, actions.getUser, 'foo')
    expect(store.handler).toHaveBeenCalled()
    expect(store.handleFetchedUser).toHaveBeenCalledWith('foo')
  })
})

I would expect handleFetchedUser to have been called but it's not

Expected spy handleFetchedUser to have been called.

Any idea? Thanks :)

In the readme it says that flummox should work with coffeescript also but I have some problems with calling super in coffeescript classes that extend classes from flummox, it throws Cannot call a class as a function
Is there a compatibility issue between js generated by Babel and js generated by Coffeescript?

Would be nice to have the ability to register a few actions at a time and more importantly I think to have a generic 'matcher' mechanism. ( @acdlite you mentioned that there is already work in progress in the area, just wanted to share ideas and also keep updated on how the impl is going to be)

Lets say I want to create a matcher that basically matches any action that has a status code 500.

I would like to have a store that does that in a simple way:

var matcher = (payload) => payload.response.status === '500';

class NotificationsStore extends Store {

  constructor(flux) {
    this.registerMatcher(matcher, handler);
  }

}

Another cool thing would be to define metadata in the action, therefore we could do a matcher that matches against that. Lets say we want to 'tag' all our navigation actions with a tag 'navigation'
then I could build a matcher in the way (payload) => payload.action.tags.contains('navigation')
and listen to every navigation action.

Thanks! really liking the library and concepts, awesome work!

The problem in issue #47 could have been avoided if a better error message were thrown.

FluxComponent and fluxMixin use the key flux for passing the Flux instance via props and context. This is a natural default, but it should be configurable to enable multiple Flux instances to be used without clashing — for example, if a Flummox instance is used locally by a component, or as part of a library.

API would look something like this:

<FluxComponent flux={fluxA}>
  <FluxComponent flux={fluxB} fluxKey="flummox">
    <InnerComponent /> // this.props.flux === fluxA && this.props.flummox === fluxB
  </FluxComponent>
</FluxComponent>

(Props passing is nice, but this is more important for preventing context clashes. In this example, descendants of InnerComponent have context flux and flummox)

The API for fluxMixin would be a bit trickier. The current args for fluxMixin() are the same as the args for connectToStores(), so it would be weird to add another arg. For this reason, I'm thinking this feature should be exclusive to FluxComponent. Also, I don't think people should use fluxMixin anyway... it only exists in the first place because I know some people are stubborn and will insist on the mixin form :)

I noticed that the npm releases are out of sync with the git tags:

latest npm release - 2.13.1
latest git tag: - v2.9.2

I have a component, which is a children of another component that is listening on some stores tied to async operations.

If I try to throw an error in this sub-component, the error is not caught because it happens while dispatching:
https://github.com/acdlite/flummox/blob/master/src/Flux.js#L119

If I sorround the dispatching code with try catch, I'm able to log the error

body => {
    try{   
        this._dispatch({
          actionId,
          body,
          async: 'success'
        });
    }catch(e){
       console.log(e);
    }
   },

I'd like to be able to re-throw the exception here, because it's useful especially while developing.
The problem is that we are in a Promise context, so the error is lost.

For instance if you throw new Error() here:
https://github.com/vesparny/flux-immutable-example/blob/master/src/components/FrameworkDetail.js#L18
You'll see that the error is silent, and in the console you can see that only the begin handler is dispatched, because the success one throws an error.

If i want to use FluxComponent where i fetch multiple items how do i loop them ?

<FluxComponent connectToStores={{ Item: store => ({ items: store.getItems(1,2,3,4) }) }}>
  <ul>
    {??.map(item => <li key={item}>{item}></li>)}
  </ul>
</FluxComponent>

Do i need a component to do the mapping ?

If i have a FluxComponent can i access other properties?

<FluxComponent connectToStores={{
  Comment: store => ({ comment: store.get(this.props.commentId) }),
  User: store => ({ user: store.get(<<<<Above comment>>>.userId) })
}} />

It looks like FluxComponent "swallows" its children so they don't show up in the components tree. Is this a known behaviour or I'm doing something wrong?

Hi @acdlite,

first of all thx for making this library, it has really nice concepts and looks really promising.

I've been playing around a little with it and there are couple of things I'm not 100% sure, so I'd like to ask you ;)

1. Let's say I have lots of stores / actions in my application. How should I use the Flux container? Should I create one for the entire application with all actions / stores declared in it or should I create many of them and instantiate them only where needed (e.g.: one for general application usage, one for a specific page, ...)?
2. With the standard singleton dispatcher, every action would go through that place, making easy to keep an history and debug. When using multiple instances though, there are "multiple" dispatchers, loosing then the ability of having everything flowing through a central place (although there are other benefits). Is that correct? Could you maybe clarify that and how would you handle that situation?

Thanks :)

Right now there is an issue if you are using the FluxMixin (the same should be true for FluxComponent) with an array and a single stateGetter like this:

FluxMixin(['storeA', 'storeB', 'storeC'], function(store) {
...
})

In this case the callback will be called 3 times (each time with one with the stores as an argument). It would be better if it could be called only one time with all 3 stores being arguments of the callback. So that we could use the mixin like this:

FluxMixin(['storeA', 'storeB', 'storeC'], function(storeA, storeB, storeC) {
...
})

This would need some refactoring inside the connectToStores and getStoreState functions.

I have this Action

'use strict';

var { Actions } = require('flummox');
var arrayUtils = require('../utils/arrayUtils');

class FavoritesActions extends Actions {

  addFavorite(id){
    var favorites = this.getAll();
    favorites.push(id);
    window.localStorage.setItem('favorites', JSON.stringify(favorites));
    return favorites;
  }

  removeFavorite(id){
    var favorites = this.getAll();
    arrayUtils.remove(favorites, id);
    window.localStorage.setItem('favorites', JSON.stringify(favorites));
    return favorites;
  }

  getAll(){
    return JSON.parse(window.localStorage.getItem('favorites')) || [];
  }
}

module.exports = FavoritesActions;

When I call the method addFavorite() internally I call the method this.getAll() and assign its result to favorites.
The problem is that favorites.push(id) seems to be executed before the method this.getAll() returns, like if it was async, and I get an error of course because favorites is undefined.

I don't know if the problem here is about something related to es6 which I'm a total noob at.

React won't display warnings AFAIK, when you are in production mode. Could there be a way to disable those messages in some fashion for production for Flummox?

Some changes in react v0.13 regarding late property validation

http://facebook.github.io/react/blog/2015/02/24/streamlining-react-elements.html

Am I right in thinking that these changes will mean that the current usage pattern for FluxComponent:

<FluxComponent connectToStores={['storeA', 'storeB']}>
  <InnerComponent />
</FluxComponent>

will now imply that InnerComponent is not allowed to do 'required prop' validation of any of the property values that FluxComponent will retrieve from the stores and eventually pass into the cloned InnerComponent at render time ...? Does this mean a new pattern should be used for this ...? Maybe passing the Component class into FluxComponent as a prop rather than a child element...?

<FluxComponent connectToStores={['storeA', 'storeB']} innerComponent={InnerComponent} />

Or maybe it would be possible to retrieve the appropriate props to pass to innerComponent at the call site ...?

innerComponentProps, storeChangeSubscriptions = flux.connectFluxComponentToStores(['storeA', 'storeB']...)

<FluxComponent flux={flux} subscribeTo={storeChangeSubscriptions} >
  <InnerComponent {... innerComponentProps}/>
</FluxComponent>

Still very new to flux and react so apologies if I have the wrong idea in any of the above ...

I have a rather newbie question. I think it could be general to how Flux works but not specific to Flummox.

How could I handle the case when in order to call an action on a store i need a piece of data from another store? The problem arises when doing server side rendering. To be more precise: I have two nested route handlers, each one needs to get some data before rendering but the child handler data fetcher depends on whatever data is fetched by the parent handler.

In my understanding it would be possible since Flow 0.4.0 to annotate the Flummox API with type information. For Flummox users it would mean that you could statically check with Facebook Flow that you are calling Flummox the right way from your application code. Sounds tempting :-)

@acdlite I'd like some advice on avoiding the warning, "setState() called from outside an action handler." The setup is that I have a store that is being asked to load data via an action. The action doesn't load the data, because the store may or may not already have the data. I have the store first check to see if it has the data, and if it doesn't asynchronously go to an api and get it. It's basically a caching issue.

This all works fine, except flummox keeps yelling at me to stop setting state outside of an action handler. Which I'm not exactly, but I get why the warning is firing.

So, I can't have the action fetching the data, because it doesn't have access to the store. I can't have the store firing another action to fetch the data because you can't fire an action within another action.

What are my options, that keep code clean and readable? I looked at Store.registerAsync, but that only seems to help if the action is asynchronous. But I want my store handler to be asynchronous. Basically I'm ok with my code working as is. I just want that warning to stop showing up.

npm ERR! peerinvalid The package react does not satisfy its siblings' peerDependencies requirements! npm ERR! peerinvalid Peer [email protected] wants [email protected]

on the features page of the project

Support for plain JavaScript class components in React 0.13.

I see there are TestUtils being worked on for Stores. Has any thought been given to Actions? I understand the rationale behind wrapping actions as a safeguard but the "magic" makes it harder to test.

I’ve written a very simple todo app using flummox@^2.11.0. It starts out with with four items, and the only thing the user can do is to delete items. The component rendering the array of items fails when there is only one item left. It seems like there is an issue with FluxComponent – it fails when containing an array consisting of one item.

Error:

Uncaught TypeError: Cannot read property 'hasOwnProperty' of undefined

Location:

FluxMixin.js:189

Here is the source:

https://github.com/unfold/flummox-todo/blob/v0.1.0/entry.js

I tried to update flummox to the lastest version in order to check if it has been fixed, but it seems like I’ve got some migration to do. (It says Uncaught TypeError: Cannot read property 'cloneWithProps' of undefined.)