-
Notifications
You must be signed in to change notification settings - Fork 1
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
Closed
WIP reboot #47
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
11b0d44
to
525bf8b
Compare
Closed
Closing, Nikki is picking this up |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Rebooting the implementation with lessons learned...