Inconsistent behaviour regarding empty strings
We have two different behaviours when dealing with "type": "string" properties,
- When the field is invalid by any rules, it removes the property.
- When the field is valid, an empty textbox creates an empty string.
This breaks the meaning of valid when dealing with this case,
- The property is not required
- The property has a minLength
- The model has that property with a valid value inside
ASF reports a valid input at the textbox, while still creating an empty string in the property which is in fact invalid.
Point 3. is not the only way to produce this, see this gist for a working demo, enter text and then delete it you'll get an empty string.
I believe this is the same thing as the issue I reported? https://github.com/Textalk/angular-schema-form/issues/436 Pretty sure! I will re-read both later to confirm. :)
As far as I read from your case we are talking of the same misbehaviour, my code is a simplified version of yours. We just use different validation criteria.
Steps to reproduce:
- Model has that value more than minLength
- Enter text more than minLength
- Remove all text in textbox
At step 3 target model property will be an empty string and still valid, which is not expected.
@davidlgj You may want to take a look in both issues, I don't think it is directly related to schemaFormValidate as you suggested in #436 .
This is somewhat ambiguous in the context of a textbox input, it does not differentiate the following results:
-
nulltypes - empty strings
- removal of the property itself
This is an abstraction problem which from the value alone is not fully translatable to the property layer that ASF skipped. i.e. Predict the property layer from user entered value.
Taking reference to another project jdorn/json-editor, they have the options to add/remove optional properties, that's one way to solve this abstraction problem. Another approach would be adding model options like "nullOnEmpty" or "removeOnEmpty".
I have this same problem, too...
@vicary is this behaviour any different in the latest alpha?
AFAICT it is unchanged. TBH I'm not sure what to expect, it's neither destroyStrategy nor default.
It's more like when $modelValue === '' we revert back to some state.
Sounds almost the behaviour of a form reset, but only on a single field.
@vicary ok, just checking after so much time... I like the nullOnEmpty config suggestion, would you expect that to be needed per-field though or would global be enough do you think?
I guess make it global until somebody suggest a legit use case on the field level.
IMO the logic behind this is a bit complicated for normal users to even care.