♻️ [#1068] -- Refactor formio integration #2388
Merged
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
Codecov ReportBase: 93.53% // Head: 93.47% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #2388 +/- ##
==========================================
- Coverage 93.53% 93.47% -0.06%
==========================================
Files 651 651
Lines 20750 20797 +47
Branches 1964 1964
==========================================
+ Hits 19408 19440 +32
- Misses 1024 1040 +16
+ Partials 318 317 -1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
sergei-maertens
force-pushed
the
feature/1068-refactor-formio-integration
branch
2 times, most recently
from
64060e9 to
0b5e7ed
Compare
The public API now uses the new/single registry for formio components, which also handles the formatting of values given to formio components.
This is now used by the component registry rather than implementing/ providing a formatter registry itself.
…port This moves it up into the openforms.formio.service module rather than in the formatters subpackage.
…stry This deletes the dynamic config-specific registry, while mostly keeping the public API intact.
…line Instead of using a fixed pipeline, the concerns are now moved to the component level that can opt-in to request-specific component rewriting. This should also lead to slightly more optimized code execution since we're looping over a caching datastructure rather than looping over the entire component tree over and over again.
First step towards refactoring how custom fields are handled, the request should not be needed as all required information is/should be present on the submission instance.
…g approach Now it's just another flavour of mutating an existing component on the fly, with the added functionality of making some network calls to retrieve the relevant data. This essentially does away with the whole special treatment of custom field types. The use case of adding one or more components and rebuilding the component tree is removed, as there has not been any demand for this. We do keep in mind it may at some point be needed to inject components at other locations in the tree or do more advanced operations, but the current implementation does not sit in the way of that approach. Additionally, this fixes the bug where only top-level npFamilyMembers components could function correctly, which is now properly recursive for nested components.
sergei-maertens
force-pushed
the
feature/1068-refactor-formio-integration
branch
from
4242b88 to
cd46627
Compare
sergei-maertens
force-pushed
the
feature/1068-refactor-formio-integration
branch
from
cd46627 to
45b5a52
Compare
The navtree was confusing and too nested, this structures the docs more along the core/modules principles and keeps the topics on a single page.
sergei-maertens
force-pushed
the
feature/1068-refactor-formio-integration
branch
from
ad4fd78 to
1dc3088
Compare
SilviaAmAm
approved these changes
Nov 25, 2022
sergei-maertens
force-pushed
the
feature/1068-refactor-formio-integration
branch
from
536133b to
5b2629f
Compare
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.
Closes #1068
This refactors and restructures how we deal with formio components in the backend, tackling all the aspects now that our codebase is mature enough to see what is used and required.
So far, every aspect has had its own registry within the
openforms.formiopackage, implementing functionality specific to that. However, it's becoming clear that those aspects also have interaction at some level (or will have this, see #2324), so the general direction is now to have ONE registry holding all the (known) formio component types as plugins, where every plugin can manage the relevant aspects.This encourages composition and keeps the concerns together per component type rather than needing multiple files for a full picture of a single component type.
Aspects: