tomkis
commented
8 years ago tl;dr: Use The Elm Architecture
Here's my proposal:
Not sure how widespread is the problem, but I encounter it from time to time. I hope the developers from the front-end community encounter similar problems, too.
Unless you like spaghetti code, the problem is indeed very widespread, because by default Redux does not force you to encapsulate (except combineReducers but that's not enough) and therefore componentize.
I believe The Elm Architecture has found the solution for all the problems above.
The principle behind The Elm Architecture is basically just simple composition. People who are using Redux nowdays definitely knows of composition... we are composing our views, state and even reducers
The Elm Architecture is doing same - except one small thing, it's composing Actions and Side Effects as well. Just imagine you could have something like:
{
type: 'PARENT_ACTION',
payload: {
type: 'CHILD_ACTION',
payload: 'foo'
}
}Fairly simple concept which solves everything.
Before reading following explanation I highly encourage you to go through The Elm Architecture description
can be instantiated more than once, maybe simultaneously (not a singleton)
Just compose actions and add ID of the instance so the hierarchy could look like Counters.Counter.1.INCREMENT where 1 stands for the index of the Counter. example in Redux
each instance can have its own configuration
Have an init action, which configures the instance (Using Action composition).
can query and manipulate the global environment:
This means to make the component capable of Side Effects... Elm solves this by reducing them in updater function (Updater is same as reducer in Redux). With Redux, there are store enhancers which supports this kind of functionality already. Please keep in mind that using Generators for side effects is opinionated and has its drawbacks, but you can always use plain old reduction as Pair<AppState,List<Effects>> which works without generators too. example in Redux
can depend on the app state:
Parent components should be responsible for orchestrating inter-component communication => therefore just simple composition, I blogged about this.
should not pollute the environment
Every Component in The Elm Architecture is independent and isolated, there's no way to access parent's component state in the child component.
when used from another app, the component should be reused, not copy-pasted
And because Components are isolated, it's fairly simple to integrate it into any other redux-based application. example in Redux
sompylasar
slorber
ghost
galkinrost
gaearon
panezhang
ccorcos
tiengtinh
mpeyper
timdorr
markerikson
jcheroske
dalgard
azizhk
hapood
stereobooster
This post is meant to be a start for a discussion. Moved from here as @gaearon suggested here.
Intro
I'm interested in finding best practices on how to architect complex components implemented in React and Redux so that they are reusable as a whole in another app.
Not sure how widespread is the problem, but I encounter it from time to time. I hope the developers from the front-end community encounter similar problems, too.
Terms and definitions
A complex component -- a UI (React, Redux actions), coupled with business logic (Redux reducer), and data access logic (Redux actions' side effects; middleware).
Traits of a complex component:
An app -- a UI environment where the components are configured and instantiated.
Traits of an app to consider:
Examples of components
Developing such components with Redux adds the invaluable benefits of predictability and replayability.
Questions to answer
React developers from Facebook answered that I should "start by reusing React components only", but having a lot of business logic copied from app to app is not the best way to go.
Elm architecture answers some of the questions, but Redux is quite different (no view+reducer coupling, no explicit serializable side-effects).
References