Idea behind this repo needs to get more attention

[minedeljkovic]

One of the bigest limits I find with classical Redux is it is not fractal (a term that is proposed and nicely explained by @staltz here). I find that to be main reason why, dispite such a strong community, there are no truly reusable and well encapsulated pieces of application (calendars, datagrids, pagers, authenticaiton components, what have you...) that are stateful in a Redux way. Most of community Redux components (middlewares, store enhancers, etc.) are ortogonal to features themselves, but not ready made features or parts of more complex feature, which is imo direct consequence of architecure not being fractal.

This repo proposal eliminates this limit, and makes Redux architecture fractal (which is no suprise since you ported Elm architecture, and Elm is fractal). Key difference, which you nicely bolded in readme, is that beside composing Views, State and Reducers (which are already composed in classical Redux), Actions and Effects should be composed, too. All that leads to composition of application pieces at the higher level. It is really interesting that, usage of organization proposed by this repo, leads to some other (imo high quality) corrections in Redux architecture - elimination of action creators, making middlewares truly orthogonal (unlike those in Redux real world examples), possibility of eliminating action type constants, etc.

Lack of this is my main concern with some new Redux additions, like redux-saga, that is gaining a lot of traction. Despite some very clever ideas and implementation done there, sagas (as is) are not composable in a fractal way with the rest of architecture, and imo are just creating more distraction instead of letting Redux community face this problem.

I wish this repo a best of luck. :)

[tomsdev]

Hi @minedeljkovic, about redux-saga not being fractal, you might want to have a look at https://github.com/threepointone/redux-react-local#extra---sagas

[tomkis]

@tomsdev actually I don't really think that redux-react-local does solve Sagas fractability. It still depends on getState function which returns root application state. Therefore if the Saga is deeply nested in the hierarchy and shape of the app state changes (higher in the hierarchy) you'd still need to change the implementation of that Saga.

[tomsdev]

@tomkis1 I think using getState in sagas is a bad practice, usually a saga should just react to actions. Also I'm pretty sure that you could give the saga the "connected" state of the local component.

[tomkis]

I think using getState in sagas is a bad practice

+1 however:

actually I was also thinking about getting rid of it in my rxjs saga version too.

I am using redux-elm with redux-saga-rxjs for production app now and frankly, sometimes it's really hard to achieve fractability for Sagas. It sounds really cool that Saga could potentially be totally unaware of application state yet it's practically impossible.

Besides, in typical Backend based implementation e.g. Axon framework Saga, "can somehow" access the app state. Sagas do not directly access the app state but they emit Commands instead of Events. Commands are handled in command handlers and therefore associated with actual application state. Command handler is responsible for emitting events based on the application state.

redux-saga is different, because it's not emitting Commands but Events therefore it probably should be allowed to access the app state inside Saga, however this totally breaks fractability.

I'm pretty sure that you could give the saga the "connected" state of the local component.

I am pretty sure this is not possible [https://github.com/threepointone/react-redux-saga/blob/master/src/index.js#L36](see here) - the library is just a proxy to redux-saga and it always uses global appstate.

[tomsdev]

redux-saga is different, because it's not emitting Commands but Events therefore it probably should be allowed to access the app state inside Saga, however this totally breaks fractability.

I have not used sagas in development yet but I feel that a reusable component's sagas should only have access to its local state and its children states.

I am pretty sure this is not possible https://github.com/threepointone/react-redux-saga/blob/master/src/index.js#L36 - the library is just a proxy to redux-saga and it always uses global appstate.

Sorry, I didn't mean it's possible with the current library implementation, I meant that it should be possible to implement it that way.

[tomkis]

I have not used sagas in development yet but I feel that a reusable component's sagas should only have access to its local state and its children states.

That's the ultimate goal, though implementation is quite hard because it would require to tightly couple reducers with sagas, still not ideal.

[tomsdev]

I think that 2.x.x solved this issue, sagas are now fractal right?

[tomkis]

Partially - yes Sagas are indeed fractal now, however we still need to spread the word and I am in the middle of writing a blog post, once it's done i'll leave link here and close this issue.

[tomkis]

There's a blog post written by @matthewgertner advocating this approach http://blog.javascripting.com/2016/05/21/the-problem-with-redux-and-how-to-fix-it/

Closing as there's nothing actionable here.