form-js-viewer refactor, splitting view and state management

[Skaiir]

What should we do?

We need to split the form-js-viewer state management logic from its rendering in two different projects.

Why should we do it?

There are many motivations for this change:

• Our reliance on preact to compute things like feel expressions, visibility, ect... is slowing us down more and more, many timing issues are created as a result of tethering render to computations and it also affects performance
• Our tests are unreliable and slow from their reliance on jsdom and waiting for UI event propagation
• Splitting the two would allow us to implement brand new renderers by interchanging
• ...

How we are going to do it?

• Bootstrap projects
  • viewer-core
  • viewer-render
• Agree on form component & form structure interfaces
• Build out new renderer project to include all components #1189
• List out all current viewer features & highlight things that need discussion
• Decide on where each feature should live
• Create a rough feature migration plan
• Migrate all functionality as needed to each project
• Integrate (needs details)
• ...

Migration (todo)

• viewer-core
• viewer-render
• other

Internal discussions ongoing, see comments for the brainstorms.

[Skaiir]

We are currently considering to build two sub-packages to handle the separation. These would be independent from each-other which means that you could either use the core package with a custom renderer, or the renderer package with any type of schema corresponding to the visual contract we want to build up between the two packages.

I briefly sketched out how we see the core architecture's direction (early ideas anyways). But we could opt for a near-stateless transformation pipeline that would look something like this:

The advantage of a pipeline like this would be that it would simply eliminate side-effects, and make the forms truly deterministic relative to the only thing that can actually change within it (the managed form state).