Version 4.x.x

[tomkis]

Version 4.x.x

[tomkis]

Hello @Dattaya thank you for your feedback :) Easiest way is to compose all the actions with following pattern Counter.1.Increment. Therefore you can us buildUnwrapper('Counter') and deal with unwrapping dynamic action right in the handler... so you would just map unwrap manually 1.Increment into const index = 1 and action = { type: 'Incremnet'} and pass it down the corresponding reducer.

The main idea is described here https://github.com/salsita/prism/tree/v3.1.0/docs/composition/dynamic-list although it's for older version of prism (called redux-elm) the idea remains the same, we have just decided not to give user facility to do use a helper function as part of the framework, because we rather put the burden on the user so that they can implement more complex use cases by themself.

[Dattaya]

Thanks, your comment was very helpful! In case anyone's interested, here's how countersPairReducer for dynamically created counters might look like:

const computeIndex = ({ type = '' }) => Number(type.substr(0, type.indexOf('.')));

const unwrapAction = (index, { type = '', ...other }) => ({
  type: type.replace(`${index}.`, ''),
  ...other,
});

const initialState = {
  counters: [],
};

export default buildReducer([{
  unwrapper: buildUnwrapper('Counter'),
  handler: (state, action) => {
    const index = computeIndex(action);

    return ({
      ...state,
      counters: state.counters.map((counter, i) => i === index
        ? counterReducer(counter, unwrapAction(index, action))
        : counter
      ),
    });
  },
}, {
  unwrapper: buildUnwrapper('AddCounter'),
  handler: (state, action) => ({
    ...state,
    counters: [
      ...state.counters,
      counterInitialState,
    ],
  }),
}, {
  unwrapper: buildUnwrapper('ResetCounters'),
  handler: (state, action) => ({
    ...state,
    counters: state.counters.map(() => counterInitialState),
  }),
}], initialState);

[stratospark]

@tomkis1 We have some key parts of our app written with redux-elm. I am all for transitioning into a simpler architecture.

I'm wondering what the consensus is about the fractal architecture described in: https://blog.javascripting.com/2016/05/21/the-problem-with-redux-and-how-to-fix-it/. This was a key article that convinced me to go with redux-elm. Do the arguments listed in that article still apply? And would be solved by a redux-elm rewrite?

[ccorcos]

I actually really like how hyperapp works -- its very similar: https://github.com/hyperapp/hyperapp

[Dattaya]

@tomkis1, thanks for the great library. I hope it's fine if post here a question: Are there helpers to deal with a situation when a user can create any amount of counters dynamically (for example by pressing a button)? Or I should build my own smarter unwrapper and handler that can distinguish and initialize if necessary Counter1_/Counter2_/.../CounterN_?

[reem]

What I really loved about the redux-elm library was that it gave a way to write a react/redux application using a truly fractal architecture. It seems like your linked "proper architecture" (mastermind) does not use a fractal architecture, it has reducers, components, sagas, etc. all separated from each other rather than grouped together. This seems like a rather different way of doing things!

While I can appreciate that the monolithic nature of redux-elm@3 was restricting, I think any new approach at v4 (or prism@1) should be designed with an eye towards enabling a truly fractal architecture, as this was (to me) the entire idea behind redux-elm, and copying the elm architecture was just a way to accomplish this goal.

[ccorcos]

If you're trying to go the declarative, pure functional approach, I think the best way to handle side-effects is the same way you handle rendering. This is how Elm 0.17 works, and here's a little example I built that could give some inspirations: https://github.com/ccorcos/arbol