Converting repeated inputs (i) and forms (f) into arrays

[alexiglesias93]

The Data Store stores inputs data (i) and forms data (f) in multiple ways:

Single occurrences

When you add a wized="element_name" attribute to an input or a form, it's stored like this:

i.element_name = "input_value"
f.element_name = { field_name: "field_value", ... }

List occurrences

When you render an input or a form inside a list, Wized knows that there are multiple occurrences of that element and converts the field to an array:

i.element_name = ["input_value_1", "input_value_2"]
f.element_name = [{ field_name: "field_value", ... }, { field_name: "field_value", ... }]

Each element's value can be accessed using the index variable that was defined in the Render list action.
For example:

return f.element_name[v.index].field_name

Multiple (non list) occurrences

This is the case scenario that we need to improve.
Currently, Wized only accepts 1 unique element for each static (non list) i or f. If the user adds the same wized="element_name" attribute to two or more elements, Wized will only keep the last one.
For example, in this scenario:

<input type="text" wized="favorite_color" value="red">
<input type="text" wized="favorite_color" value="green">

Wized will store the value for the last instance, overriding any other:

i.favorite_cat = "green"

This is probably not the desired result for most people. If they add multiple inputs or forms with a same name, they would expect to be able to access their value.
So I think we need to update the behavior to this:

i.favorite_cat = ["red", "green"]

Now, the problem is that we currently have no way to access each element's value from inside an Action.
Let me put a real live example:

A developer wants to create a multi-step form, breaking down each step into an individual form.
The developer would apply wized="step_form" to each <form> element, creating the following output (I just made up the fields):

f.step_form = [
  {
    name: 'John',
    email: 'john@doe.com',
  },
  {
    interests: ['javascript', 'node.js'],
    age: 25,
  },
  {
    country: 'United States',
    city: 'New York',
  },
];

A total of 3 steps (forms), each one containing the inputted data.
The developer wants to display the next step when the user successfully submits each form, so he adds the following Actions:

Action 1 - displaying the current step form

• Attribute: step_form
• Action: Set visibility
  • return v.step_index === FORM_INDEX

In this Action v.step_index is a variable that defines the current step to display, and FORM_INDEX is what we need to solve, it must define each form's index so each form will only be displayed when v.step_index is equal to the form's index in the f array.

Action 2 - incrementing the current step index

• Attribute: step_form
• Action: On Event
  • Event: submit
  • Sub Action: Set variable
    • Variable: v.step_index
    • return FORM_INDEX + 1

In this Action FORM_INDEX is again what we need to solve, it must define the submitted form's index so we can increment it by 1 after submission to proceed to the next step.

The potential solutions

Each form element's index could be exposed via t.index.
The t keyword belongs to the target element of each action, so in this case it belongs to each form element.

t.index would be:

1. t.index = ELEMENT_INDEX when the element is repeated multiple times (non list) on the page.
2. t.index = undefined when the element is unique on the page.
3. t.index = ?? when the element is rendered in a list. This scenario is tricky to define as the element could be rendered in a nested list, which means that it could potentially have multiple indexes, not just one. I need to give this scenario some further thoughts, feedback is appreciated.

If we update the previous example to use t.index, it would look like this:

• Action 1 - displaying the current step form: return v.step_index === t.index
• Action 2 - incrementing the current step index: return t.index + 1

I think this could work, but I am not 100% convinced because of the uncertainty for t.index in rendered lists (3rd bullet in the previous list).

Hence this RFC, I would love to read the community's comments and thoughts and see if we can find an ultimate best solution to this problem.

[BarthMedia]

@alexiglesias93

Couldn't you assign a unique ID/index to the form/form wrapper - and the children's mapping would then be unique due to the uniqueness of their parent elements?

Still learning wized, so might not fully grasp the context... :)

[alexiglesias93]

If I understand you correctly, then this would be the same as just adding a unique name to each input/form element 🤔
So instead of having 3 forms with the same name and storing them in an array like this:

f.step_form = [
  {
    name: 'John',
    email: 'john@doe.com',
  },
  {
    interests: ['javascript', 'node.js'],
    age: 25,
  },
  {
    country: 'United States',
    city: 'New York',
  },
];

We'd have 3 different names with 3 different form objects like this:

f.step_form_1 = {
  name: 'John',
  email: 'john@doe.com',
};

f.step_form_2 = {
  interests: ['javascript', 'node.js'],
  age: 25,
};

f.step_form_3 = {
  country: 'United States',
  city: 'New York',
};

Correct?

If this is what you mean, this approach is already possible right now. But it has the downside of requiring a hard-coded name for each element, which would mean that users would need to create an Action for each element instead of being to reuse a single action for multiple elements.

[BarthMedia]

Okay. I'm starting to understand what you are trying to achieve with the approach above (probably also interesting for me when I integrate StudioForm ;) - because it should probably be in the same format)

Do you have an example project or a loom?
And do I understand you correctly that you only have a problem in terms of creating a sensible indexing for forms within nested lists?

[BarthMedia]

@alexiglesias93

Hope this might helps -> https://www.loom.com/share/7f36faccf1a042f68df88240a4745e09

[Manki32]

Ok, I see the issue with this...

What if we don't allow multiple forms with the same attribute?

What would be the downside here? You can still apply the same action to multiple elements.

For example:
https://i.imgur.com/Rb8ReEr.jpeg

This way, only rendered lists will be an array.

You can still display the correct step, by applying this action on the form_wrapper element:
return t.node === t.parent.children[v.current_form].node

In this case, the container that has all of the forms has also a Wized attribute applied.

This is how I have it set up currently, and it works really well.

If your multistep form is in a rendered list, you can just replace v.current_form with the parent's state t.parent.data.current_form or am I missing something?

[Manki32]

Loom with my current setup:
https://www.loom.com/share/d453036923784d9b95c70d0102c12489

[BarthMedia]

What's the state on this @alexiglesias93
Found a solution for the indexing issue?

[alexiglesias93]

We'll post an update soon with a new RFC that goes deeper into the lists rendering topic and potential new approaches. I'll share it in the beta testers channel when it's posted 🙂