React components communication strategy

Status: being evaluated
Deciders: Pietro, James
Date: 2018-10-05

Context and Problem Statement

Deciding how to have the internal components of the Transcript Editor communicate with each other.

Decision Drivers

Simple and straightforward way to reason around passing data between components
Extensible anticipating use cases when using the component "in the wild" and having internal info accessible/when if needed.

Considered Options

Parent component
Flux / Redux
Event driven eg pubsub-js

Decision Outcome

Still evaluating, leaning torwards some light refactoring to enable parent component, option 1 to keep things simple.

Pros and Cons of the Options

Parent component

[example | description | pointer to more information | …]

pointer to more information - see Blog post - "8 no-Flux strategies for React component communication"

Good, because With some light refactor, if needed, could be the most straightforward and lightweight implementation
Good, because It might make the component easier to test with automated testing

Bad, because it might not extend well for use case when you need to have insights on what's happening inside the component, eg use selecting text, or clicking on words, playing media etc..

Flux / Redux

pointer to more information - Flux/Redux

Good, Allows to have single source of truth in a store and not communication from sibling to sibling,
Bad, Might be overkill for what we are trying to do, keeping things simple and limiting the learning curve for newcomers to the project.

Event driven eg `pubsub-js`

Pointer to more information - pubsub-js

Good, could provide a clean interface for other components when used in other applications. Eg if you want to be notified every-time some text is selected in the editor, or video is playing etc..
Bad, Might be difficult to test
Bad, might cause issues with keeping track of local state