how to add forms / input elements validation about elix HOT 6 CLOSED

You raise a really interesting issue here: there are two conflicting goals for what the type property should do:

1. In order to be a drop-in replacement for the native input, the Input component should expose a type property that mirrors the type on the inner native input.
2. According to this explainer on form-associated components, a component should expose a type property that returns its localName.

The specific quote:

The following properties and methods aren't strictly required, but native form controls provide them. Providing them helps ensure consistency with native controls.

We'd followed that guidance in writing FormElementMixin — but hadn't noticed that this conflicts with point #1 above. In retrospect, I'm really unclear on what, exactly, is the value of point #2 above. The wording is vague, and I'm having trouble understanding where type would come into play with forms.

I'm wondering whether we should drop the definition of localName as type everywhere, or at least drop that in Input so that it can expose a type property that mirrors in the inner input type.

If you have thoughts on that, please let me know.

As for your question about validation, we're still trying to work out a good canonical pattern for having a component like NumberSpinBox perform form validation. We're still thinking about the best way to do that. Again, if you have thoughts on the topic, I'm interested in hearing them.

from elix.

I would love to help, not sure that I am qualified, though (not really up to date with all those new APIs).

Haven't read through the entire article you linked, but it looks like they (@arthurevans & Co) consider the type set implicitly with the custom component, and are shying away from elements like INPUT having multiple types. Not necessarily a bad thing, considering the variable behavior (visual, validation) of native INPUT accross browsers and the difficulty to handle them as a single generic input component (imho even big frameworks like Angular or React struggle to unify input elements; I certainly did not enjoy the experience). Still, it would be interesting to hear what they have to say about this particular problem --the fact that it is not covered in the article is intriguing!

As far as Elix is concerned, like I initially wrote I'm not pushing for using the native input validation (which might resullt in visual glitches on some browsers), would just (respectfully) expect the framework to have a component for each of the usual native types, validation included (localization being a 'small' additional challenge). Rome was of course not built in one day...

I plan to revisit this issue after contributing to #113.

from elix.

Since I was tagged here, I'll offer what clarity I can. I'm a writer, not a spec author or a browser engineer, but I did consult with the spec author and one of the Polymer engineers for this article.

There's nothing normative in the spec about the type property. The example in the spec uses a getter that returns localName for type, and I followed suit. I did ask about this, and as the code sample in my article says, there are a few fields like type that are recommended, but not required.

I think the idea here is that:

1. as @geonanorch said, the magic input element that does something completely different based on its type value is problematic. If you're creating a new input component, it's probably better to do one thing really well.
2. Returning a type of localName feels a little weird, but at least it uniquely identifies the component type, which may be useful if the value it returns isn't identical to one of the built-in form controls.

That said, if you're creating a component that basically wraps a native input, you might want to use the built-in types. I know some custom element sets do that. Both paper-input and mwc-textfield do, for example. (Neither of them use the form-associated custom elements API as far as I know.)

Again, the spec doesn't say anything one way or the other. If it walks like a "text" input and talks like a "text" input, it's probably OK to call it a text input.

from elix.

Thank you @arthurevans, I was hoping for your feedback. The clearer the way the API is meant to be used, the better for developers (and end-users) :-) If you have input about validation as well, please do chime in again!

@JanMiksovsky, to me Arthur's explanation fully support your first goal of drop-in replacement, what do you think? Whether the type attribute is then passed on to the inner native input is another decision. For some types it should be safe to do so and hence use the native validation (text, password, email, url, ...). For others Elix already has specialized components (DateComboBox, NumberSpinner, Calendar*, ...), and for best visual consistency you could instruct developers to use those instead of Input (setting their type attribute accordingly). You could even block some type values from being accepted by Input, or (a bit less harsh) fallback to text for some of them in order to preserve style. The latter implies adding validation as well.

Speaking of validation, the primary topic of this issue. Again I do not claim to be highly qualified, I can only mention some problems I see when relying on browser validation:

• styling of validation messages is as far as I known out of control, at any rate difficult to unify. Maybe not a real problem since consistent for a given browser: the user will not be surprised.
• the language of validation messages is determined by the browser's locale, which might be different from the locale of the website being visited. Maybe not mainstream usage, but also not totally uncommon and annoying.

Mozilla has a lengthy page about the validation topic (including localization), and there are certainly other resources out there. I plan to have a closer look and would let you know if I can see a clear path.

from elix.

Sorry the slow response here, and thanks to everyone for their input.

I've checked in a change to FormElementMixin that tries to strike a compromise.

• If the mixin is applied to a base class that defines a type property, the mixin respects that type. In particular, if the class is defined by WrappedStandardElement, and the inner element is an input, then this will return the type of that input.
• If the base class does not define a type, the mixin provides a default type that's the local name of the element (as it did previously).
• If neither of these answers is desired, the component author can always override type to provide a better type.

There is still much to investigate when it comes to properly supporting components as form elements, but I believe this should address the original issue.

from elix.

@JanMiksovsky Thanks a lot, sounds like an elegant compromise, I'll test it with the next release.

And no complaints about the delay, it's not like I was particularly active on that topic... In fact I am sorry, my gut-feeling is that the architecture of Elix should lend itself well to a generic / clean validation approach, but I would need to invest enough time to understand how it works exactly to be of help...

from elix.