Skip to content
This repository has been archived by the owner on Dec 19, 2024. It is now read-only.

What is the API a custom element must use to be iron-form compatible? #217

Open
rjcorwin opened this issue Sep 10, 2017 · 3 comments
Open

Comments

@rjcorwin
Copy link

rjcorwin commented Sep 10, 2017

I figured it would be having name and value attributes and dispatching a change event but I see that <iron-form onchange="...">... doesn't fire when my custom elements dispatch change event. I also have to figure out the API for validation. I tried reading through the iron-form code but I've been unable to figure out the API. Can anyone help point me in the right direction?

@ianjosephwilson
Copy link

I'm still learning polymer and trying to use iron-form myself. I don't think iron-form utilizes on-change other than in that demo. Your custom-element should probably dispatch a change event with bubbles and composed set to true if you want to watch the on change event like that demo example to be received past a shadow dom barrior.

Otherwise I think there are two types of interfaces. When a form is submitted first the validatable elements are validated, if the form is valid, then the submittable elements are serialized and submitted:

validatable elements

  • must have a validate method that takes no arguments, return true if valid, return false if invalid
  • disabled must either not be set or set to false for the element's validate() method to be called

submittable elements

  • must have a name and a value
  • disabled must either not be set or set to false for the element's name and value to be submitted
  • multiple name and value pairs will be consolidated into an array under the name, as I understand it

@rjcorwin
Copy link
Author

rjcorwin commented Sep 13, 2017

Thanks so much for the research summary @ianjosephwilson. I like the idea of everything submittable having both name and value attributes. Unfortunately the standard HTML element select and paper-radio-group both diverge from this concept in strange ways.

I've proposed in the paper-radio-group element issue queue that we use the standard name/value approach PolymerElements/paper-radio-group#86. That proposal would fix a strange standard HTML spec, radio buttons sharing the same name attribute is totally a weird standard that needs to go away. Radio buttons should be options in a select list kind of element that actually follows the name/value idea.

Also weird in standard HTML, checkbox and their checked attribute. Why not just <input type="checkbox" value="checked">/<input type="checkbox" value="">? Either there needs to be a real type system with HTML forms or everything a string.

In regards to validating elements, IronFormElement.validate() is nicer than standard HTML of InputElement.checkValidity(), but unfortunate we have to remember two different standards on that one. It's either bike shedding or it's a mistake on the design of Iron Form Elements API.

@rjcorwin
Copy link
Author

@ianjosephwilson I'm working on a project for the next 8 months that relies on form elements in Polymer for the next 8 months. If you are also working on this actively we should hangout! Feel free to reach out to me at [email protected] or [email protected].

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants