Should a state live in a procedure environment?

[ceving]

I am still struggling with web development and I would like to discuss the following observation.

Imagine a web application, which is a sequence of forms each containing a sequence of input fields. The DOM might look like this:

• App
  1. Form
     1. Input
     2. Input
  2. Form
     1. Input
     2. Input

Every input should be validated, every form should be validated and all forms should be validated. Because the input has an impact on the validation, both are states. When I put each state in a variable, which lives in an environment of a procedure, each validity can only be defined after the corresponding input, because the validity depends on the input, the same for the combined validities. In the end the definitions will have the following order:

var app_form1_input1
var app_form1_input1_validity
var app_form1_input1
var app_form1_input2_validity
var app_form1_validity
var app_form2_input1
var app_form2_input1_validity
var app_form2_input1
var app_form2_input2_validity
var app_form2_validity
var app_validity

This is exactly the opposite order of the DOM tree.

VanJS advocates two aspects:

1. Procedural composition of the DOM tree
2. Storing states in procedure environments

But the shape of the procedures building the DOM tree is contrary to the shape of the procedures working on the states. How does this fit together?

The alternative would be to store the states right in the DOM tree. Every element, which needs validation, can store the validation state in its dataset. And when a validity of an input element has changed the element can emit a bubbling custom event. It will bubble the DOM tree up and every element on its way can react to the event by updating its validation state. This works right out of the box without any help of a toolkit. Is seems to me that for this particular use-case a DIY solution is much easier than a solution using VanJS.

[Atmos4]

It feels like your thinking is a bit more complicated than it needs to be.

Every input should be validated

This is not true. You will give yourself a lot more trouble if you try to validate all inputs all the time. In the end when it comes to data submission, only backend validation matters. Frontend validation is only something nice for the user that you can perform sporadically.

procedures

I don't understand your usage of the word procedure. If you want granular input validation, you are perfectly fine doing it in the input field level with van.state and care about global form validation on submit.

all forms

Given the way HTML forms work, thinking about form submission with multiple forms on the same page doesn't make a lot of sense, since only one form should be submitted at the time. If you have many forms you want to validate and submit at the same time, it might be that you are thinking about form submission in a wrong way.

Keep in mind doing any kind of validation in the frontend (i.e. Javascript) is not secure as anyone could bypass it. It should just be viewed as a nice UX bonus, nothing more.

PS: You might want to take a look at this community add-on dedicated to form state management with VanJS.

[Tao-VanJS]

This problem occurs only, if you put states into procedure scopes.

You can definitely put all the states into the global scope. I don't see a problem with global-scoped states.

[ceving]

Yes but then I have the same situation as in the past. I have the definition of the DOM in one place and all the logic in another place. I would like to have some kind of encapsulation. The creation of the DOM elements and the logic, which deals with the elements and the events they produce, belong together. The essence of the whole problem is, that the creation of DOM elements is a top-down job, but managing state-changes is a bottom-up job. When I put states into the DOM, while the DOM gets created in order to read the states with getElementByID this works, because getElementById implements some kind of lazy evaluation. But when I put the state into the environment of a procedure, I give up the laziness, because JavaScript is eager. I think the makes the whole idea of having states in ordinary JavaScript variables questionable.

[ceving]

BTW: when I say procedure I mean something which behaves in this way:
https://sarabander.github.io/sicp/html/3_002e2.xhtml#g_t3_002e2

[ceving]

I think I would like to be able to write something like this.

main({id:'main'},
     state({id:'validity'},
           () => state_set('validity', and(state_get('f1', 'validity'),
                                           state_get('f2', 'validity')))),
     form({id:'f1'},
          state({id:'validity'},
                () => state_set('validity', and(state_get('i1', 'validity'),
                                                state_get('i2', 'validity'),
                                                state_get('i3', 'validity')))),
          input({id:'i1', oninput: e => state_set('validity', validate_f1i1(e.target.value))},
                state({id:'validity'})),
          input({id:'i2', oninput: e => state_set('validity', validate_f1i2(e.target.value))},
                state({id:'validity'})),
          input({id:'i3', oninput: e => state_set('validity', validate_f1i2(e.target.value))},
                state({id:'validity'}))),
     form({id:'f2'},
          state({id:'validity'},
                () => state_set('validity', and(state_get('i1', 'validity'),
                                                state_get('i2', 'validity'),
                                                state_get('i3', 'validity'),
                                                state_get('i4', 'validity')))),
          input({id:'i1', oninput: e => state_set('validity', validate_f2i1(e.target.value))},
                state({id:'validity'})),
          input({id:'i2', oninput: e => state_set('validity', validate_f2i2(e.target.value))},
                state({id:'validity'})),
          input({id:'i3', oninput: e => state_set('validity', validate_f2i3(e.target.value))},
                state({id:'validity'})),
          input({id:'i4', oninput: e => state_set('validity', validate_f2i4(e.target.value))},
                state({id:'validity'}))));

I it verbose to make it understandable.

But in general the variable lookup needs to be done in the opposite direction as it is usually done when procedures are evaluated. Procedures search for missing variables in their parent environment. But in the DOM a parent needs to lookup variables in its children.

[Tao-VanJS]

I am not sure if I can express my feeling about this. It seems that you're trying to pursuit the perfect solution based on your specific criteria for a very special-case scenario. But IMHO, day-to-day programming primarily focuses on getting the problem solved in a reasonably maintainable way. Sometimes there are trade-offs but programmers just move on.

[Tao-VanJS]

But the shape of the procedures building the DOM tree is contrary to the shape of the procedures working on the states. How does this fit together?

Not sure what you meant by this. Do you have a concrete example where things are running into troubles?