Restructuring the repo for easier componentisation

[chrishutchinson]

Hi all. I had a great chat with @pietrop today about this project, as I'm keen to contribute and use it at The Times. A few things came up, particularly around making the sub-components of the app available for re-use (as I'll want to bring a lot of my own UI and other logic for our use case, but would like to share the common bits). This issue is to discuss an approach to doing this.

Is your feature request related to a problem? Please describe.
As above, I'd like to make the sub-components of this app available for re-use. At present, it's pretty hard to only take the text editor, or the media player, without bringing the entire rest of the application.

Describe the solution you'd like
To achieve this, I'm proposing we transition the repo to a monorepo (powered by Lerna and Yarn Workspaces) with a small number of sub-packages, each of which can be pushed to NPM (or equivalent) as independent React components. This would allow for a consuming app (like mine) to install the components it needs, and bring it's own for the areas where either:
a) it needs something bespoke (e.g. user authentication, custom settings UI)
a) bbc/react-transcript-editor doesn't provide that feature, and it doesn't make sense for the overall roadmap
c) I want to replace a component for a one-off use case

Having tinkered with this, I roughly imagine we'd have the following packages in the monorepo:

• @bbc-transcript-editor/app: A fully composed version of the app, which can be rendered in a standard create-react-app and allow someone with little-to-no desire the customise the app to get started
• @bbc-transcript-editor/media-player: The media player, including all play/pause controls etc.
• @bbc-transcript-editor/settings: The settings modal
• @bbc-transcript-editor/timed-text-editor: The core DraftJS-based transcript editor
• @bbc-transcript-editor/adapter-{FROM}-{TO}: A standardised set of adapters, replacing the existing adapter / converter logic (e.g. BBC Kaldi to DraftJS, or DraftJS to SRT).
• @bbc-transcript-editor/context: A React.Context wrapper, the root of all instances of the Editor, which provides default global config options, allows developers to register active adapters, and handles the globally-utilised analytics callbacks. (To do this, all components would need to be updated so they were context-aware. This would be done more easily if we upgraded to React 16.8, as we would have access to the useContext hook).
• @bbc-transcript-editor/util-{UTILITY_NAME}: A set of utility packages that are used across the app. (These could be a single utility package, depending on the extent of shared code)

Alongside this monorepo, I propose we use Storybook to provide a simple UI for exploring the available components, and a convenient development environment.

Describe alternatives you've considered
There are a number of possible blockers to a monorepo, including:

• The BBC unable to namespace packages under @bbc-transcript-editor on NPM (would require senior signoff)
• Unwillingness to use a monorepo solution. In this case, we could explore using a set of modular named exports, or sub-folders from one very large NPM package. These options do come with downsides

Equally, there are alternative tools to Storybook, a good example would be React Styleguidist.

Additional context
In the interest of getting some initial thoughts on this, I have forked bbc/react-transcript-editor and put together a very basic monorepo + Storybook app so contributors can get a feel for how it might look / work. All the details for that (screenshot + setup commands) can be found on this PR: chrishutchinson#1

Note: The above was thrown together in about an hour, so there are lots of rough edges, lazy copy-pastes, and temporary names. It's all for the purposes of the demo, a proper monorepo approach would tidy all of this up! 😄

[pietrop]

Thanks @chrishutchinson !
As mentioned, I am in favour of this, I hope to dive deeper into the example you linked to sometime this week (most likely by Friday) - also need to discuss with @jamesdools

[pietrop]

Thanks @chrishutchinson as mentioned in PR #122 closing in favour of PR #130 but happy to further discuss this, and further optimise at a later stage