Closed bob2517 closed 8 months ago
For example, in an SPA, let's say there is a pre-rendered form, hidden or displayed, and you are making a fresh JSON call to fetch data for one record. ACSS automatically converts JSON data to variables. When the JSON is received, one assignment from the JSON variable to a defined form variable object could update all the details in the form without having to do anything else, in addition to the display fields.
The form fields can then be shown when the edit button is clicked on, the regular display fields disappear - the input fields reshow, and voila, you have an accurate form ready to be submitted. That is a more scalable solution than any vdom technique, as you are only dealing with record data and variable placeholders in the DOM.
It does require that you are in control of the JSON to control field structure, but it would be weird if you weren't.
It would not work with forms that have a potentially different field structure for each form, without some other logic in there, and it may be simpler just to draw a form in that scenario, but those types of form tend to happen less frequently.
This is now being handled as an either/or. If the attribute being updated is named "value" then it sets the property and not the attribute. Otherwise the attribute itself is changed. In theory there should be a slight performance improvement if using reactive variables with value attributes due to no visible rendering needed when updating, and won't affect ajax-form-submit or a regular form submit which has always used the value property and not the attribute value.
Now on branch. Closing pending release.
Currently, putting a reactive variable in an input field, doing some typing and then changing the reactive variable, doesn't update the property of the input field. It only changes the attribute - not what you can see.
But if you don't change the value property by typing, changes to the value attribute, via a reactive variable, does update the property. It's a bit niche, but that's what the browser does.
I can't think of a valid reason why you wouldn't want the property to change also if you specifically set up a reactive variable for the value attribute.
So I think it would be good to also change the property of an input field if the attribute changes as a result of an changed reactive attribute. This wouldn't violate existing behaviour, because the browser doesn't natively support reactive variables yet, and you would specifically have to set it up in the code anyway. As I say, I can't think why you would want to update the value of an input field dynamically without also updating the value property.
This would mean that CRUD forms would, in scenarios set up to utilise this behaviour, be easier to write and require less mark-up. So here's the issue for it.