Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
1 of 9 tasks
Skaiir opened this issue Apr 25, 2024 · 1 comment
Open
1 of 9 tasks

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

Skaiir opened this issue Apr 25, 2024 · 1 comment
Assignees
Labels
in progress Currently worked on

Comments

@Skaiir
Copy link
Contributor

Skaiir commented Apr 25, 2024

What should we do?

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

grafik

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 make implementing new renderers in potentially other frameworks / different toolkits rather simple
  • Removing the viewer's dependency on the viewer would be a nice improvement as we currently do some quite hacky things with it

How we are going to do it?

  • Agree on form component & form structure interfaces
  • Build out the form-js-render package #1189
  • Build out the form-js-viewer-core package  #1208
  • Migration of custom components
  • Integrate the new packages into the viewer
  • Build out the editor "core" submodule (defines what the editor will supply the renderer, we don't need a full package for this, as it'll be small)
  • Integrate the module + the renderer into the editor
  • Consider integration concerns into other products
  • Final checks

Internal discussions ongoing, see comments for the brainstorms.

@Skaiir
Copy link
Contributor Author

Skaiir commented Apr 25, 2024

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:

Sketching render pipeline

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).

@Skaiir Skaiir self-assigned this Apr 30, 2024
Skaiir added a commit that referenced this issue May 6, 2024
Skaiir added a commit that referenced this issue May 8, 2024
Skaiir added a commit that referenced this issue May 8, 2024
@Skaiir Skaiir added the in progress Currently worked on label Jun 11, 2024
Skaiir added a commit that referenced this issue Sep 2, 2024
Skaiir added a commit that referenced this issue Sep 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in progress Currently worked on
Development

No branches or pull requests

1 participant