Make it optional to initiate data

[perifer]

Hi, and thanks for a great lib!

I have come across a use-case where it would be useful to not have to initiate all properties up front. It's a create-form with lots of form fields, where having to initiate all of them would be cumbersome. This is Laravel and what we would like to do is to pass some initial values by serializing a new model, but by doing that the attributes that are not set will not be serialized.

The use-case is somewhat similar to this issue in Vue where they eventually changed a behavior in Vue 2: vuejs/vue#5932 (comment)

When looking through the code it struck me that you are doing some work in guardAgainstReservedFieldName() to allow setting properties directly on the Form class, so my understanding is that is not as simple as moving the form data to separate object on the Form class.

[perifer]

I just realised that the issue I referenced has the answer to why the data is stored directly on the Form class - Vue only allows reactive properties that doesn’t exist one level deep.

[sebastiandedeyne]

Yeah, I'm afraid this would lead to reactivity issues, so gonna have to keep it as is.

[perifer]

We managed to find a good enough solution for our use-case. The solution with guardAgainstReservedFieldName() feel a bit nonoptimal though. It's not that far fetched that a form could have fields with names like "data", "delete" etc.

[sebastiandedeyne]

If I'd rewrite this package, I'd probably put all values under form.values to get around this problem. But that would completely change the API, so keeping this as is for now :)

[perifer]

But wouldn't that break the reactivity of those values, since they would not be "one level deep" anymore?

I was thinking one option was to move everything else, and keep the data on the form object. That would still break the API though.

[sebastiandedeyne]

Pretty sure it would be possible to mark them as reactive somehow.

…

On 24 Mar 2020, 10:16 +0100, Anders Fajerson ***@***.***>, wrote: But wouldn't that break the reactivity of those values, since they would not be "one level deep" anymore? I was thinking one option was to move everything else, and keep the data on the form object. That would still break the API though. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or unsubscribe.

[perifer]

Yeah, definately worth looking into.