Combining Stateless Stores

combining.js

// ------------
// counterStore.js
// ------------

import {
  INCREMENT_COUNTER,
  DECREMENT_COUNTER
} from '../constants/ActionTypes';

const initialState = { counter: 0 };

function increment({ counter }) {
  return { counter: counter + 1 };
}

function decrement({ counter }) {
  return { counter: counter - 1 };
}

export default function counterStore(state = initialState, action) {
  switch (action.type) {
  case INCREMENT_COUNTER:
    return increment(state, action);
  case DECREMENT_COUNTER:
    return decrement(state, action);
  default:
    return state;
  }
}


// ------------
// todoStore.js
// ------------

import { ADD_TODO } from '../constants/ActionTypes';

const initialState = {
  todos: [{
    text: 'do something',
    id: 0
  }]
};

export default function todoStore(state = initialState, action) {
  switch (action.type) {
  case ADD_TODO:
    return {
      todos: [{
        id: state.todos[0].id + 1,
        text: action.text
      }].concat(state.todos)
    };
  }

  return state;
}


// ------------
// combinedStore.js
// ------------

// Let's say at some point I know that these stores depend on each other in some way.
// If I *decide* I want to hide these stores as impl details of a single store
// I don't need to change their public APIs at all. I just register combinedStore instead.

import counterStore from './counterStore';
import todoStore from '../todoStore';

const initialState = {
  counterData: undefined,
  todoData: undefined
};

export default function combinedStore(state = initialState, action) {
  const counterData = counterStore(state.counterData, action);
  const todoData = todoStore(state.todoData, action);
  return { counterData, todoData };
}


// So it's trivial to "merge" stores but keep the delegation. This is exactly how Elm models work too.
// Now, if I *want* to, I can make substores more custom (e.g. make a store factory that responds only to
// actions matching predicate, like createFollowersStore(userId) => FollowersStore that responds to specific
// userId in the action). Composition all the way!

You might want to revive this

Anyway, I would say that the need to use waitFor to keep particular order of handled actions is most likely caused by wrong architectural decision. Stateful store is supposed to encapsulate specific domain and the state is responsible to determine those boundaries. However, if the store is stateless and entire state of app is held in single tree, the decision about store boundaries is not that strict and we create those boundaries only to make our code logically grouped together (we could possibly have just single store to handle all actions, which is of course not ideal). The tree itself is responsible for emitting change for specific views which really need to update. So in other words, if we really need to rely on order then it's probably better to handle everything in single action handler, but in most cases we could avoid it by proper schema of the tree.

By separating the concern of how your application state handles actions (the writes) and how to read your application state then store boundaries become a lot less important.

Ultimately it's the ability to compose your application state and view it through any lens that makes a singular tree-like app state very powerful.

This was a very conscious design decision of NuclearJS. By having the overarching framework be responsible for dispatching actions and notification it allows all observers to get a singular immutable snapshot of the world every dispatch loop.

The hard part is performance. By having everything in a singular app state map or store then using a store boundary as the unit of measurable change doesn't work anymore. In NuclearJS we chose to use ImmutableJS, which made deep quality checks in a map relatively free at the expense of enforcing ImmutableJS throughout the stack (not necessarily a bad thing)

Am very interested to see how this library evolves!

This looks awesome because it resembles more and more to the architecture exposed in Elm (https://github.com/evancz/elm-architecture-tutorial) sans the signals concept (which isn't a lot to grasp anyway). I love it because of its simplicity, and flexibility to acommodate different state requirements. It's just functions and composition, as simple as it gets.

As i see it you have two type of dependencies for data. One is store dependency on data a and second one is derivated data.
For first problem my ideas is this:
Lets see stores as "entities" which provide initial states and some reducing functions over this state. Combining these two into one function which react on action and decide which reducing function should be run and you get exactly this lib. If your application is fair simple than this might be enough for you. And what for more complication situation? What about two stores depend on each other? Easy way to grasp this is to abandon idea of simple dispatching in original flux. What if we take building blocks of stores in this lib(initial states and reducers) and remake dispatching. For every action there will be one place(one meta-store or you can split it between multiple stores-stores) which will be responsible for calling reducers over corresponding parts of state. Then you can precisely control what reducers/in what order and with what data will be called. This will also add you ability to pass reducers not only state from one store but for multiple stores. For keeping this design sane reducer can modify only state in their responsibility like now but can read(depend) on multiple stores data. You will not need waitFor because you will have explicit dependencies stated in this meta-store.

On derivated data story. If you have DRY state than this state is usually not best for ui. Derivated data in their essence are pure functions over multiple store data which returns this data combined somehow. So without any further attempt in component you can subscribe to multiple stores and feed their values into this pure function and use result of this in rendering. This is not enough if you want to reuse this in more than one component which are not is child-parent relationship(can be passed as props) or if you don't want to expose this dependency between stores inside rendering and have it outside. With little bit of effort this abstraction can be implemented that derivated data for components will look like store and components can reed them and listen on it. From dispacher point of view after he run action through stores he will recalculate derivated data and only after that will issue change events to component. For performace reason you can use imutable data and caching results of derivated functions.

Hi,

Dan your idea looks similar to what I use in https://github.com/stample/atom-react except we have different API's

For me a store is just an element that project events to a state

I don't have yet this API but will tend to evolve to something akin to this:

var todoStore = function(cursor,event) {
}
var counterStore = function(cursor,event) {
}

var  someComposedStore = function(cursor,event) {
  todoStore(cursor.follow("todos"),event);
  counterStore(cursor.follow("counter"),event);

  // Custom code can be plugged here, by using the content of the other stores
  var todoNumber = cursor.follow("counter").get();
  cursor.follow("moreThan10").set(todoNumber > 10);
}

var  rootStore = function(cursor,event) {
  someComposedStore(cursor.follow("someComposedStore"),event);
}

eventStream.wireTo(rootStore)

Being able to compose stores inside another store permits to remove the store dependencies with waitFor, without introducing too much code duplication.
It generated some extra storage and immutable data copying but it has not been a problem for me until now.

Hi,

I like your idea of redux and composing stores but I see the same problem as @alexeyraspopov mentioned regarding combininig independent stores. The reason is, that the container component must know the composition hierarchy. Therefore previously independent store/component combinations would be coupled with other stores.

Therefore I would propose to provide an alternative way to combine stores in a flat way.

The combining function would look like this:

export default function combinedStore({counter, todos} = initialState, action) {
  ({ counter } = counterStore({counter: counter}, action));
  ({ todos } = todoStore({todos: todos}, action));
  return { counter, todos };
}

The composeStoresFlat would like like this:

function composeStoresFlat(...stores) {
    let storeMapping = new Map();

    let internalStores = stores.map(store => {
        let initialState = store();
        let keysForStore = Object.keys(initialState);

        keysForStore.forEach(key => {
            if (storeMapping.has(key)) {
                throw new Error("Two stores provide state for the same identifier: " + key);
            } else {
                storeMapping.set(key, store);
            }
        });


        return (state, action) => {
            return _.pick(store(_.pick(state, keysForStore), action), keysForStore);
        }
    });

    return (state, action) => {
        let newState = {};
        internalStores.forEach(store => {
            Object.assign(store(state, action));
        });
        return newState;
    }
};

The initialization of redux would be done in the following way:

const dispatcher = createDispatcher(
    composeStoresFlat(combinedStore, anotherStore),
    getState => [thunkMiddleware(getState)] // Pass the default middleware
);

const redux = createRedux(dispatcher);

Finally the component needing the counter information can select the counter independent of the todos and vice versa. Hence it allows to reuse stores and corresponding container components independent of their composition:

state => ({ todos: state.todos })

counter => ({ counter: state.counter})

@speedskater

I understand what you're suggesting but I'm sure it's going to be a pain in a large app to keep inventing keys so they don't clash, and it will look exactly the same namespaced way in the end.

I think that the problem of components tied to particular state keys is better solved by composing their select methods. This is exactly what NuclearJS does with "getters". It's already possible in Redux but not really documented yet. Here's some info:

reduxjs/redux#160 (comment)
reduxjs/redux#47

@fisherwebdev I just published a small middleware that i think can help you solve that problem: redux-next I hope it helps but it doesn't quite react to the store though... :P

Here are a cople of other middlewares i made redux-delay and redux-client-next (middleware creator function) lol @ my useless contributions

I can see the benefit of combined store that rules them all so stores don't have to talk/depend on each other, however i.e the combined store now owns the dependency as one abstraction level up, this is more likely to be more readable and easier to manage as an application grows.