Improve template pattern mechanism

[andreasrs]

This ticket is a result of my idea-pitch + following discussion in person with DLMR. It is mostly to document these thoughts/findings so that we can act on them in the future.

Current solution: Roc has functionality-merge across extensions and a custom-made hooks+actions concept in place today.

The roc object with its settings + commands etc. provides an easy-to-use interface for customizing different types of behaviour when using Roc. The available settings are pre-defined by the current package and plugin selection and are really easy for the user to adjust in their project. These are also mapped out to the CLI so that they can be overriden using the command line easily.

Hooks+actions lets users or other packages/plugins perform custom operations at selected critical points in the ecosystem. It allows the injection of javascript functions to modify behaviour. For example adding loaders to a webpack configuration.

The Roc objects for all packages/extensions are merged using code provided by roc cli project to compose features from different packages.

Positives:

• It all works
• Also has pretty smooth auto-generation of documentation in MD format
• Declarative definition of Roc object in each package makes it easy to see what each package brings to the table

Negatives:

• Completely custom implementation, no well-known library with familiar interfaces at the core
• Hard to keep track of the "big picture" as more and more packages and plugins merge and also have actions at many different hooks in each layer.
• The Roc object extension and hook/action functionality can be a bit tricky to grasp. On the other hand it can be countered by making great documentation and cleaning up the interfaces a little
• Limited flow control in hooks/actions
• A bit unconventional way of passing data values, like previousValue argument.

Proposed (new) solution:

• Use a single state of truth (using something like Redux) for maintaining the entire Roc object throughout it's lifetime, including settings.
• The CLI now has a single source of truth for everything; updated in a predictable manner
• Any modification to the roc object at any point follows unidirectional flow, dispatching suitable actions with descriptive names.
• A package or plugin simply exports a function (for example) that dispatches a set of actions to carry out the required modifications with the appropriate values. The actions can of course be re-run later with different values to modify or override behaviour.
• A package or plugin brings their own actions, reducers and potentially middlewares.
• Redux middlewares can then be used throughout to achieve the overriding of any behaviour or add custom side-effects in a consistent way.
• End users then have two things:
  • Easy-to-use settings that can be adjusted like today. Also through cli options
  • Possibility of adding redux middlewares for complete control when necessary. Very short and predictable path to creating custom re-usable plugins.

Positives:

• Uses a tried & proved library for handling the complete roc state that the roc cli then uses
• Uses a tried & proved library for handling flow through middlewares that also provide next() functionality
• Actions and reducers can be re-used in middlewares at any time
• Can prove very useful in Roc tooling if the package graphs grow large enough
• Opens up possiblities to use existing tools that can aid us in the future (for example redux-saga for side-effects or similar)

Negatives:

• Documentation auto-generation that currently works today must be ported to work with Redux.
• Redux is mainly designed for long-lived apps that receives a lot of user-input and state modifications, today we are not yet sure if our package graphs and number of actions will be large enough for it to be truly needed
• Using things like redux-dev-tools in this context will not be trivial
• Implementation of this is not trivial given the size/ambition of the project, the cost/benefit factor does not fully convince us.

Suggestion to way onwards:

• Carry on building Roc on the current object merge + hook & action infastructure.
• Set up a pull request on a small subset of the packages that uses Redux instead to try it out conceptually.

=> Evaluate how it works in practice on a small subset, and then consider a larger adjustment if it works really well in a PoC.

I can take responsibility of making this PoC, and will do it in the near future.

[dlmr]

I suggest we close this issue and revisit this at a later time, thought @andreasrs?