Presets for plug-and-play functionality

[i-like-robots]

This is a subject we have touched upon several times but we're getting close to the time we really need to implement it.

We have a lot of building blocks which can be used to build apps and deliver them. The requirements of the current set of FT.com apps are complicated. To build or migrate an FT.com app you'd need to begin by installing almost everything:

• Anvil CLI (WIP)
• Anvil FT CSS plugin (complete)
• Anvil FT JS plugin (WIP)
• Express
• FT Navigation middleware (complete)
• FT edition middleware (complete)
• FT A/B middleware (complete)
• Assets middleware (complete)
• Handlebars renderering (complete)
• JSX renderering (WIP)
• Handlebars/JSX interop module (TODO)
• JS client-side bootstrap (WIP)
• FT UI layout (WIP - this includes the shell, header, and footer components)
• Base FT client-side JS (TODO - ads, analytics, error capturing)

In addition each component may require specific configuration and integration. To avoid having a complex and lengthy step-by-step guide how could we bundle all of this functionality to make it more approachable and plug-and-play?

[i-like-robots]

My thoughts:

• CLI with JS and CSS plugins should be fine, they don't require bundling further
• Bundle navigation/edition/A/B middlewares into a single preset
• We'll need to try slotting the asset loader, bootstrap, renderers, and UI components together to see how they fit before making a decision.

[magsallen]

Chunking the components into presets makes sense. 👍

Adding the middlewares as a bundle should be reasonably straight-forward, (if we assume all FT consumers will want to include all three) and the layout should be ok too as most of the logic is already in n-ui.

We'll want to keep the number of manual configurations at each step to a minimum so it's probably worth thinking about the steps involved so they can each feel distinct and reasonably simple. There's a trade off between the number of unique bundles/installation steps and how easy each step will be to understand, so that's worth considering too 🤔

[i-like-robots]

Having been working on the migration of a few apps I'm not yet convinced we've seen repeatable enough patterns to commit to anything, but my current feel for this is as follows:

• dotcom-middleware-preset - returns an array of route handlers, self-explanatory
• dotcom-ui-preset - includes calling React.renderToString() etc. this is somewhat tricky though because to make it a truly useful module this may need to know about the request/response objects 🤔 (update, maybe not cc Wrapping HTML responses with the shell and layout components #524)

[i-like-robots]

I'm going to close this issue. Whilst migrating apps it's become clear that the gaps between the different parts can be very useful and so far feedback suggests teams appreciate seeing how things work and having less indirection.

I hope that #524 and #528 will provide the desired ergonomics that this issue was originally intended to provide.