Modifying forms (f) and inputs (i) behavior

[alexiglesias93]

Both forms and inputs are defined by adding a wized="my_name" HTML Attribute to the <form> or <input> elements.
By default, Wized generates a f.my_name or i.my_name namespace in the Data Store and populates the values like:

• f.my_form is populated when the <form> emits a submit event.
• i.my_input is populated when the <input> emits an input event.

This behavior is ok as it encourages users to rely more on form submissions, which is usually the best practise when dealing with forms.
But that's not always the case, and we've seen many users wanting to modify the behavior (specially in forms) to be populated on other events like change.

So, I think we should allow users to modify the event that is used to populate the Data Store namespaces.

I can think of two options to do this:

1. A new wized-trigger="EVENT_NAME" HTML Attribute

Simple approach where users would simply add an additional HTML Attribute to the form/input element that already has the wized="my_name" attribute.
For instance, if a user wants a specific form to be updated on change instead of submit, he would add two HTML Attributes to the form:

1. wized="my_name" attribute to identify the form.
2. wized-trigger="change" attribute to modify the behavior.

Pros:

• Very simple and straightforward.
• Technically easy to implement and ship.

Cons:

• We're moving logic from the Wized Configurator to the Webflow project, which may not be the best approach when thinking about project organization/scalability/maintanability. Separation of concerns is important.

2. A new settings panel for forms and inputs

Allow users to modify this behavior directly from the Data Store, by opening a new settings panel when clicking on an input or form entry:

This approach may be simpler to unexperienced people and has the advantage of preserving the logic inside the Wized Configurator.

Pros:

• Logic is contained inside the Wized Configurator.
• Easier to maintain.

Cons:

• More complex to implement and ship. We'll have to think about edge cases like:
  • What happens if a user modifies a form's behavior (so the new behavior is stored in the project configuration), but then removes the form from Webflow?
  • Should we do periodic scans and throw an error in the Debugger when this happens?
  • Should we remove the config silently when we detect that the form is no longer there?

Open for community suggestions!

[BarthMedia]

Will include my Slack message to summarize my thoughts about it.

Ideally in my mind, would be when a user selects an Action of a form (or input for that matter) and get's then a new checkbox displayed underneath the attribute dropdown.

If he checks the box, he can modify the "Data Population Event" input. In essence it should work technically very similar to how the attribute approach would work. But the interface would stay in Wized instead of moving to Webflow Attributes.

[ruairimcn-fs]

Great input Leon!
I agree. Doing this as an Attribute would work but keeping the logic in Wized is better.

[ruairimcn-fs]

This will be a great feature, one I would use a lot!
I like both options.

I feel option 1 will work because there is often a lot of work done in Webflow on forms:

• Adding error messaging
• Adding 'request in progress' spinner/loader
• Adding fields, setting Wized attributes and field names
• Some forms have conditional visibility

and so on. So given we're often in Webflow a lot for forms, I think adding a few extra attributes will be fine. There are a lot of settings for forms and form fields already, this is like a new setting but in the form of an attribute.

That said we could go for option 2 and just quietly delete the form config info if the form is deleted. Given it's a binary of 'submit' or 'change', if you accidentally deleted a form, even if had 20 fields it would be pretty quick to go in and set the configs per field again.

So my vote is for option 2. I think the technical challenges it poses are worth it, as keeping as much logic as possible inside of the Wized configurator is important for scalability as you said @alexiglesias93 .