shawnbot
commented
4 years ago Okay, I've mulled this over and here are a couple of things that I think we (I) need to do, in approximately this order:
-
Audit our existing forms for existing address components: both ones with the
addresstype and the ones that our custom address component classes (via different versions of our theme) have generated. (Until recently, the component class was generatingcontainercomponents that the form.io portal doesn't treat as "address" types.) -
Bring the design (content, data, and visual) of our ideal address component to the forms working group and hammer out how it should really work: which fields it needs, which ones are required, and potential customizations that it might require for individual forms.
-
Write a thorough test suite for address inputs that ensures it behaves as we expect it. We should consider integration tests with form.io that ensure the roundtrip from portal/builder → server → client/renderer doesn't change its behavior.
-
Rebuild our custom address component to pass the tests and any additional QA.
-
Update (some? all?) existing address fields to use our new component.
So, we have a pretty hairy problem with the address component. It's complicated, and the behavior of the component differs pretty greatly depending on how the component was added to the form.
When you drag a component into the form in the portal, the "builder" gets the default schema of the component from its class definition. The important part of the schema to note is the
components, or children, which will be a list of components from either the formio.js built-in Address component or our custom Address component.Whichever schema is read by the form builder gets saved to the form definition, and always overrides whatever we have in our theme. That's why, when the built-in Address component is used, our theme still renders the set of fields defined in formio.js (rather than our theme). And, even if we've added one of our custom components, updates to the schema in our theme will be ignored because the component's children on the server "win" when they're merged at runtime.
When we instantiate forms with components as
{type: 'address'}and (basically) nothing else in the schema, as in examples.yml, the default schema is read from our component class at runtime and merged into the one defined in YAML. Because the schema we've provided doesn't have acomponentskey, the one in our component class "wins". This is why our examples all render our address inputs.So, here's how this is breaking right now:
Neither of these is doing the right thing, because the schema that they were locked into doesn't include the right
customClassfields that get the spacing right. #125 was intended to fix vertical spacing between the city and ZIP inputs on smaller screens, but only works for our example components; any form with the components locked in ignores the custom classes we've updated in the default schema.The other thing that's complicated is deciding when to "customize" the address component:
If we use custom JS on the portal to tell the form builder about our component, we should give it a default schema that renders the component at least somewhat accurately in the builder.
We could also modify the component class to override the schema at runtime, which would give us tighter control over how fields are rendered in new releases of this theme.
However, if we override the schema at runtime, then form designers can't customize the address fields in their forms unless we build a custom editing UI for them.
There might also be a better way to control the field rendering in the template rather than via custom classes in the schema. Need to investigate this.
There are a couple of different ways that we can fix this, but they all have positives and negatives. I'll enumerate those in a bit, but I wanted to get this down for now and reach out to the form.io folks for some advice before embarking on a solution.