Fragmented State

As requested by @jbucaran in the slack channel, I am posting a request for fragmented state. The idea would be to map the namespace of actions to the namespace of state, such that the action actions.text.changeText, instead of receiving the global state, would receive state.text as state. Or actions.robots.robotarm.crush would receive actions.robots.robotarm as state.

Below would be a simple example:

app({
  state: {
    counterActions: {
      counter: 0
    }
  },
  view: (state, actions) => <h1 onclick={actions.counterActions.click}>{state.textActions.counter}</h1>,
  actions: {
    counterActions: {
      click: (state) => {
        state.counter++;
        return state;
      }
    }
  }
})

The benefit of this would be:

• It is using convention over configuration. There is no need for a lot of boilerplate to map a specific set of actions to a specific part of the state, simply include both in the matching namespace. It is always clean, easy to understand, and well organized.
• It can easily be used to keep code isolated and reusable. Below, counters and robots are completely self contained:

import {counterState, counterActions} from 'counters';
import {robotState, robotActions} from 'robots';
import view from './views/robotCounter';

app({ 
  state: {
    counters: counterState,
    robots: robotState
  }, 
  actions: {
    counters: counterActions,
    robots: robotActions
  }, 
  view: view
});

I think this would be extremely simple to implement: simply modify app.js:init() around line 37, to return a property instead of the entire state. I would be happy to make the change myself, if people think it is a good idea.

Thanks for your time. Please let me know if there is anything that is unclear, or you have any other questions.

[zaceno]

@selfup Yes, att least to allow for it. At the moment, every action needs to know about the structure of the entire state object in order to work, making any effort to separate concerns into different modules kind of pointless.

I see it more as an improvement on the Elm way, as going against it 😃

(Btw I think you meant to say “Law of Demeter” 😉 )

[jasoncslaughter]

@dodekeract: Yeah, I agree, I think it would be better to be opt-in for global state, and by default have a state that matches the namespace. So, if you wanted actions to have access to the global state, you would put them actions.global, otherwise they would go in actions and be mapped to state.

My goal is to create the PR this Wednesday night, so if this idea seems bad, or there are problems that need to be resolved, or people just aren’t interested - let me know.