You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In attribute coercion, the docs explain that binding an attribute as null will effectively remove it now.
This introduces a new breaking change when handling native forms which, I think, should be documented more clearly:
<form><selectname="mySelect" v-model="mySelect"><option:value="null">Please select a value</option><option:value"1">One</option></select><button>submit</button></form>
This will now render as <option>Please select a value</option> , when in Vue 2, it was <option value>Please select a value</option>.
This does not matter when accessing the value in Vue where it will still be null, but when you submit the form, the native value will now be Please select a value instead of empty string. For example, the above code would redirect you to /?mySelect=Please+select+a+value. In Vue 2, it was /?. Same thing when accessing the values as event.target FormData.
This is a pretty daunting change and should be much more clearly stated imo.
The migration path here is probably to replace all option null bindings to '' bindings. Which can be quite annoying really, as it now adds a new extra transformation step for your models that you always need to keep in the back of your mind.
It is not very common to integrate Vue in native html forms anyway, unfortunately. While we're at it, I think that the guide should point to the power of html validation, with constraints via attributes. Sure, JS validation has its place, as well as validation libraries, has its place, since html is limited to string values. But arguably in most cases, html is enough, and often more reliable. And especially given Vue's low barrier entry and its tendency to draw novice programmers, we should explain this in more detail. Maybe in the cookbook? There is no Vue 3 cookbook entry about forms yet anyway (?)
The text was updated successfully, but these errors were encountered:
so to keep the option as an empty value when used inside <promise-form> or similar. This is necessary to keep the syntax consistent with Vue 2. Also explained here vuejs/docs/issues/1295
(cherry picked from commit 5dd37788cd92d3d433db005f819563fa49ff05ea)
I'm in the middle of migrating to Vue 3 and just ran into this issue. It's relatively easy to swap out null values for empty strings or 0's depending on the context, even though it's annoying. But i still don't see the point behind this change. Why has it been made? Seems to me that undefined should be the only value that explicitly removes an attribute.
In attribute coercion, the docs explain that binding an attribute as
null
will effectively remove it now.This introduces a new breaking change when handling native forms which, I think, should be documented more clearly:
(link to the complete jsfiddle)
This will now render as
<option>Please select a value</option>
, when in Vue 2, it was<option value>Please select a value</option>
.This does not matter when accessing the value in Vue where it will still be
null
, but when you submit the form, the native value will now bePlease select a value
instead of empty string. For example, the above code would redirect you to/?mySelect=Please+select+a+value
. In Vue 2, it was/?
. Same thing when accessing the values asevent.target
FormData.This is a pretty daunting change and should be much more clearly stated imo.
The migration path here is probably to replace all option
null
bindings to''
bindings. Which can be quite annoying really, as it now adds a new extra transformation step for your models that you always need to keep in the back of your mind.It is not very common to integrate Vue in native html forms anyway, unfortunately. While we're at it, I think that the guide should point to the power of html validation, with constraints via attributes. Sure, JS validation has its place, as well as validation libraries, has its place, since html is limited to string values. But arguably in most cases, html is enough, and often more reliable. And especially given Vue's low barrier entry and its tendency to draw novice programmers, we should explain this in more detail. Maybe in the cookbook? There is no Vue 3 cookbook entry about forms yet anyway (?)
The text was updated successfully, but these errors were encountered: