2.0 Rewrite

[bcardarella]

This rewrite represents a few years of pain and suffering finally being overcome!

Unfortunately this will be a major API change and the upgrade path is not yet obvious. Considering that 1.x relied so heavily on private APIs I don't know if we can even support a clean upgrade path from Ember < 1.10 apps.

This rewrite will require Ember >= 2.10 positional params bug which wasn't fixed until 2.10 (see: emberjs/ember.js#14533)

The goals for this rewrite are:

1. KISS. 1.x of this library tried to do too much. And from what I can see in the eco system, the addons that have come about to replace 1.x of Easy Form are also doing too much. This leads to bloat of the libraries and means the complexity to maintain is high. Instead 2.x and moving forward will keep as simple as possible.
2. No dependencies. There won't be any 3rd party dependencies that will be required to build a form. Instead you can opt-in to using other libraries, for example if you wanted to replace f.submit with an ember-async-button we'll support an API to add f.async-submit or something like that. Want to use ember-power-select? Great, an API hook will be provided and now you'll have {{f.power-select "country" options=countries}}
3. Use HTML Constraint Validations. The HTML5 Validation API has come a long way since 1.x of this library. Back then there was good reason to work around it to provide the desired UX for form validation display and correction. Today getting that experience correct between desktop and mobile (without even considering other platforms) is difficult. Let's avoid the conversation all together and just rely on the browser to display our validation messages instead. We'll lean on the Custom Constraint API for setting the validation messages. However, we will not rely on the inline constraints such as required, pattern, etc... as we still believe that the validations should be represented in the data model and not in the form. This will reduce a lot of code and solve a lot of bikeshedding around how best to display errors. Styling will required eval of the constraint psuedo classes as well as any other custom styling the browser permits. This library will not attempt to apply classes or states to the controls for validation state.
4. Highly customizable. Templates and components should be easily overridden to provide points of customization for consuming apps. This library should serve only as a starting point with some common sense APIs for a much larger and complex form implementation that is required of the consuming app. This would also provide 3rd party libraries to give out of the box styling from grid frameworks or other custom styling packages.

As a note, credit should be given to @martndemus's ember-form-for as I believe it is currently the most complete solution in the market. There are some philosophical differences that motivated me to resurrect easy-form over contributing to form-for, but for many use-cases form-for should be a great solution. It is still not clear if 2.x of easy-form is a good idea and this PR should, for the time being, be seen as a complete experimental branch and not relied upon for anyone's app until otherwise stated.

[Trevoke]

Any idea when this will be merged in / released ?

[bcardarella]

@Trevoke it is blocked by some things I need / want to get into ember-cli's build system. Specifically, I want ember-easy-form to be able to "discover" any form-controls that are available and then dynamically create the component template hash as a pre-compile step. In order to do this the way ember-cli is building its assets need to change. I have an early version of the RFC for this here: https://github.com/ember-cli/rfcs/pull/82/files

There are other major benefits to ember-cli exposing the pre-compiled asset graph as a single tree rather than its current piece-meal approach. So I'm hoping to win over some hearts and minds to get this on the roadmap.

tldr; not anytime soon :(

[k-fish]

There are some philosophical differences that motivated me to resurrect easy-form over contributing to form-for

I've been looking at the existing form solutions, and I'm really curious as to what these differences are or what you feel form-for is lacking. Are there parts of it that don't align with current Ember paradigms?

[bcardarella]

@k-fish this isn't remotely ready. I am blocked on some upstream changes in ember-cli. If you are looking for something today you should go with form-for

[k-fish]

Ah no, I wasn't under the impression that it was ready, I'm just interested in your opinion on form-for 😄 and what the philosophical differences are, considering I was thinking of using it.