Flummox Store backed by Backbone Models?

[nambrot]

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.

[nambrot]

I guess the real question I'm asking without knowing flummox internal too well (yet), is whether this interferes with setState or whether I will need to .emit('change') manually on every mutation

[acdlite]

Right now you'd have to emit a change on every mutation. State in Flummox stores is an object of keys mapped to values. The values can be any data type, but the state object itself must be an object, as in React. Though there's technically nothing stopping someone from attaching state somewhere else on the store, you'd have to re-implement a lot of conveniences like setState(), replaceState(), and serialize() / deserialize(). FluxComponent would continue to work, but only if you specify custom state getters.

This is based largely off the way state works in React components.

I haven't tried to integrate Backbone models with Flux before, but my initial instinct would be to put them not in your stores, but in between your actions / action creators and the server. (In this Flux diagram, they would go in the Web API Utils box: https://github.com/facebook/flux/blob/master/docs/img/flux-diagram-white-background.png.) Then in your stores and components, you can use plain JS objects and arrays (or even better: the Immutable.js equivalents) as your "models," which is more in line with the React way, in my opinion.

[nambrot]

Thanks for the insights as per usual!

Yes, I would probably still set the backbone object on the state itself, thus I could reuse the defaultStateGetter right? serialize()/desrialize have to defined regardless? I would have to register a change listener on the backbone object though and trigger forceUpdate

I'm currently actually using Immutable.js for my stores, I just feel like I might end up re-implementing a lot of Backbone. Does Flummox even have the concept of ActionCreators? I assume I'm supposed to use Async Actions right?

[acdlite]

@nambrot Yeah, Actions in Flummox are ActionCreators. It's a bit confusing because since announcing Flux, Facebook changed the terminology a bit so that an "action" is the payload that is sent through the dispatcher, and "action creators" are helper functions that dispatch them. People use the terms interchangeably, unfortunately.

Essentially, what you're asking for is for state to be an opaque data type, so it's easier to override the default state behavior. Right now, it's not — there are a few places that assume that state is an object. (Or at least I believe there are. Either way, would need to confirm and write some tests.) I think that's definitely worth considering.

[nambrot]

Yeah, I think you got to the point of it. It's like being able to treat the state object as an object in the OO sense, so that you can do something like this.state[id].isValid? (instead of this.isValid?(this.state[id])) or this.state[i].update(new_attr) (instead of `this.state[id] = assign(new_attr)).

Though admittedly, I do not have enough complex-app experience to be able to judge which one is better from a readability/maintenance standpoint.

[nambrot]

I'll close this as my main question has been answered, having Backbone Collections/Models be the state of the store is not particularly Flux/React. It's more boilerplate frustration similar to #63

[acdlite]

#68 will allow you to use any type of data as the top-level state object.

[masylum]

It actually works pretty well for me:

  constructor() {
    ...
    this.collection = new Collection([]);
    this.state = [];

    this.collection.on('all', () => {
      this.setState(this.collection.models);
    });

  find(id) {
    return this.collection.get(id);
  }

  all() {
    return this.state;
  }

  onFetch(threads) {
    this.collection.set(threads);
  }
}

[nambrot]

Yeah, I use Backbone in my other React project (without Flux/Flummox) as well and it certainly works and it also is nice to have access to the backbone model itself (as well as its relationships). The only issue I see is that you effectively subscribe to every event that happens on the models and I can totally see how that potentially leads to problems down the road where you need to know what caused that change. I believe "being more Flux/React" makes that relationship more explicit (though not sure whether always worth the overhead)