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

WIP reboot #47

Closed
wants to merge 17 commits into from
Closed

WIP reboot #47

wants to merge 17 commits into from

Conversation

sergei-maertens
Copy link
Member

Rebooting the implementation with lessons learned...

Due to a different direction of implementation, the existing is being
scrapped and the configuration aligned with the formio-builder
repository. Additionally, I feel like we can get away with only
publishing ESM instead of ESM + CJS.

Next we'll port over some base components from the open forms SDK and
formio-builder repositories.
This roughly defines the top-level API and supported props for callers.

The caller feeds a form configuration and optionally an existing
submission with declarative form field values. Configuration and values
need to be processed to evaluate any component-level logic, and after
evaluation, the form field tree can finally be rendered.

We intend to provide a callback to the caller for when a form field
value changes, providing a full view of all the data in the form so
that the caller can kick off whatever is needed as a reaction.

Form state management will be done with Formik, so we can defer the
onSubmit callback and let it be passed in as a prop, which will only
trigger when all client-side validation passes.

Challenges to solve at some point:

1. editgrid component, probably the change context will need to include
   the parent component as well. We also need to check what the logic
   behaviour is, if it can look outside its scope.
2. Currently we only support simple show/hide client-side logic, but
   there are more complex situations possible we might want to use in
   the future. The logic evaluation should ideally be single-pass and
   guaranteed to resolve (cycle detection needed).
3. Styling/CSS and the default component library for the actual
form field rendering.
4. We need a generic way to pass our onChange callback into
   Formik's change handlers at the field level. This is usually
   easier to follow and more performant compared to useEffect
   tricks. Perhaps we need our own Field component build
   around useField.
ttypescript is deprecated, but ts-patch appears to be a drop-in
replacement.
Without these, the build breaks when importing from the entrypoint.
Adapted for TypeScript and slightly different approach in how
the Formik hooks/components are used, with lessons learned
in the SDK.

This results in a succesful build, but untested if it also
works at runtime. For that, first upgrade Storybook to
v7 so we have a platform to render/test these components.
* Nuked existing storybook config and replaced with v7 setup
* Ensure typescript + storybook works
* Set up react-intl translation infrastructure so that SB
  works properly
* Added missing babel dependencies as that's the SB infra

Most of this configuration is copied over from the formio-builder
project.
Loading it in full, as it's only relevant for development/reference
and we don't need to bother with a sass toolchain (yet).
Not a perfect match, but this should help in getting closer to how the
SDK looks like visually.
Each formio component type will get its dedicated React component
that knows how to render it, with the necessary component type
information fed to it.

Using the TS definitions, we ensure that all types implemented/known
are covered, while keeping a generic interface for all render
components.
@sergei-maertens
Copy link
Member Author

Closing, Nikki is picking this up

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant