Scoped reducers

[MichalZalecki]

Hi @dacz,

I think implementing scoped reducers are worth considering. This what redux users are familiar with. That's my implementation as an example:

• createState.js
• state.js#L6

[dacz]

Hi @MichalZalecki,

that's elegant solution, indeed! Thanks! I was thinking similar way...

Question is where to implement it in the flow. Because we handle all actionsStreams (messageStreams) independently (unlike redux, where one reducer may incorporate multiple actions), I was thinking to add it to the end of each messageStream (after the reducer function is created and before any merging/combineReducers are done.

And because in Redux it is based on the name of the reducer (may be configured, but each reducer maintains it's own state), multiple our message streams may work on the same selected state. That's why I'm thinking about some 'blueprinting' of an app, like:

const appBlueprint = {
  monitor: true, // because it is a stream, anybody can subscribe to it and do what she wants to do.

  initialState: {
    clients:        { data: [], ts: 0, status: undefined },
    filter:         '',
    selectedClient: '',
  }, // kind of state documentation, too.

  actionsBlueprint: {
    clientsDataLoading: {
      reducer:       true, // this is default
      stateSelector: [ 'clients' ]
    },
    setFilter: {
      pipe:          'fnName1', // like: fname1 = blueprint.stream.setFilter$.debounceTime(100);
      reducer:       true,
      stateSelector: [ 'filter' ]
    },
    selectClient: {
      reducer:       true,
      stateSelector: [ 'selectedClient' ]
    },
    receivedClientsData: {
      pipe:           'logThisDataWithinEntryPhase',
      reducer:       true,
      stateSelector: [ 'clients' ]
    },
    fetchClients: {
      pipe:    'fetchData',
      reducer: false
    },
    // timerExample: {
    //   source: Rx.Observable.interval(2000), // will generate data every 2 sec and pushes them to stream
    //   reducer: false // this will not goes into reducer but may be used as a stream by anything what needs it
    // }
  },
};

What do you think?

Would you like to become contributor to this repo? It is my first public repo and I'm quite inexperienced in how to handle contributors and PRs so please just tell me and I'll figure it out :)

[MichalZalecki]

Hi, sorry for late response. Regarding "blueprint", I prefer convention over configuration (maybe Hapi is exception here). I think it's better to keep things as simple as possible even for the cost of some code duplication, but maybe it's just me. When it comes to contributing It's hard to say. I could consider using rxr in some next project (don't know when yet) and if I decide on rxr I'll probably start making PR's. Keep up the good work!

[dacz]

Sorry, too. I was a little bit busy. I understand you (convention over configuration) and KISS principle. I came up with the blueprint idea because I was thinking about how to define which part (if not the whole) part of the state should maintain the stream. In Redux multiple "cases" (switch statements) are grouped in one reducer which made implicit grouping/scoping. I hope to have first working demo with blueprint till the end of next week so I'd be happy to know your feedback. And thanks @MichalZalecki , for your kind words!