RFC: Reuse complex components implemented in React plus Redux

[sompylasar]

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:

• can be instantiated more than once, maybe simultaneously (not a singleton)
• each instance can have its own configuration
• can query and manipulate the global environment:
  • the URL and the history (routing, back-forward)
  • network communication (AJAX, WebSockets etc.)
  • storage (cookie, localStorage, sessionStorage etc.)
  • viewport dimensions, global events like viewport scrolling/resizing
• can depend on the app state:
  • query and manipulate other components
  • delegate some functionality, e.g. asset loading, full-screen modal container etc.
• should not pollute the environment
• when used from another app, the component should be reused, not copy-pasted

An app -- a UI environment where the components are configured and instantiated.

Traits of an app to consider:

• can be a React + Redux app
• can be a React-only app
• can be a non-React app

Examples of components

• a wizard, a multi-step form, a questionnaire
• a complex stateful popup, like a multi-tab settings dialog, or a chat
• a WYSIWYG editor with autocompletion and image uploads

Developing such components with Redux adds the invaluable benefits of predictability and replayability.

Questions to answer

• How to structure the component code (where to put reducers, actions, UI code)
• How to put a component into a React + Redux app
• How to put a component into an app that has no Redux and/or React
• How to isolate the state of the component instance
• How to configure the component reducers' logic based on the component instance configuration
• How to target actions at specific component instances' state
• How to handle actions of a specific component instance in the app reducers
• How to bridge the component with the global environment (URL and history, network, storage)
• How to bridge the component with the app state
• How to bridge the component with the functionality provided by an app (asset loading, full-screen modal container etc.)

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

• Similar discussion, but not so broad: React, Redux for complex nested forms #123
• Similar discussion, but about just actions / reducers / side-effects: Recommendations for best practices regarding action-creators, reducers, and selectors redux#1171
• Similar question: Thick clients applications redux#1314
• Related: reusable components, distinguishing events? redux-saga/redux-saga#62 Though I'd like to avoid sticking to redux-saga until these sagas' state is serializable as well as redux state to at least survive a page reload. ( Time-travel and hot reloading redux-saga/redux-saga#22, DevTools for Sagas redux-saga/redux-saga#5 )
• Related: Using Redux in reusable React component redux#1098
• Related, about action types convention: examples - how to implement action type namespacing ? redux#786
• Related: Redux modularization redux#913
• Related: Reducer querying redux#943 (comment)
• Related, reducer logic customization: BurntCaramel/flambeau reducer props
• https://github.com/erikras/redux-form
• https://github.com/tonyhb/redux-ui
• https://github.com/erikras/multireducer
• https://github.com/acdlite/reduce-reducers
• https://github.com/artsy/react-redux-controller
• https://github.com/Wildhoney/ReduxLocal
• https://github.com/gcazaciuc/redux-fractal
• https://github.com/tomchentw-deprecated/redux-component
• https://github.com/wcjohnson/redux-components

[tomkis]

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]

@tomkis1 Thanks for this great overview! I'm familiar with the Elm Architecture, but the missing piece was this library https://github.com/salsita/redux-elm/ which looks like new kid on the block.

Several real-world questions aren't yet answered for me, but I'll study the examples from this repo first.

[tomkis]

@sompylasar Please keep in mind that it's not a framework nor library, it's just a proof of concept that we can write Elm like programs using redux. Good thing is that using this approach will solve many problems which otherwise needs some solution while using redux.

[slorber]

@tomkis1 I like the Elm architecture and it seems perfect to handle local component state, however I think it's missing something for real world apps.

Wrapping actions according to the dom tree structure means at the top your mailbox basically only receive some kind of global action like APP_STATE_CHANGED, and it's the deeply nested payload of that action that actually holds the useful action. So if you have an app with a lot of counters everywhere, at very different nested levels, it seems pretty hard for me to listen to ALL the increment actions of ALL counters, and display that value somewhere.

I've written something here and did not get any good answer but maybe you can try to solve my counter problem? evancz/elm-architecture-tutorial#50

By the way, I'd appreciate if you wanted to contribute to this TodoMVC-Onboarding with an Elm architecture solution.

[slorber]

@sompylasar maybe the DDD part of my anwser here can interest you: reduxjs/redux#1315 (comment)

[sompylasar]

@slorber 👍

@sompylasar Thanks for the kind words in reduxjs/redux#419 (comment). I believe everything in my article, React, Automatic Redux Providers, and Replicators, covers most of your questions and provides solutions for nearly all of them. I'd be glad to answer any specific questions. In advance, if you can include some background/reasoning behind your questions, it would help me answer them to the best of my ability. :)

[sompylasar]

@timbur Yes, thank you, I'm very excited with the article, that's exactly what I was looking for. I'm still reading it now, I'll ping you here if something comes into mind. One thing for now is I wonder how would redux-saga fit into the proposed architecture.

[galkinrost]

In our applications we solved problem of isolating component's logic in a connect-like style. https://github.com/Babo-Ltd/redux-state

[sompylasar]

More ideas here: reduxjs/redux#1385 (comment)

[gaearon]

Relevant new discussion: reduxjs/redux#1528