RFC: API redesign

[anehx]

RFC: API redesign

[anehx]

Hi @makepanic

Thank you for your feedback! 👍

A random thought from my side would be to decouple any css framework compatibility from core.

Do you mean putting the themes in separate addons (e.g ember-validated-form-bootstrap)? Or would it maybe be enough to just filter out all unneeded code on build?

So something like the following configuration would allow a user to specify which component will be used for any validated-form form field type. This reduces copy pasting when specifying a custom rendering component.

You're absolutely right! We had the same idea but forgot to mention it in the RFC. I added it to the optional features, since this is not something crucial.

One could maybe also allow aliasing so "render": "bootstrap" would tell the addon to bundle the default set of bootstrap form components ("render": "foundation" to bundle foundation components and so on).

A global option for a default set of components is definitely reasonable.

FYI: I already added a very very basic partial implementation of this RFC in #128. If you want, take a look at it and give us your feedback!

[makepanic]

Do you mean putting the themes in separate addons (e.g ember-validated-form-bootstrap)? Or would it maybe be enough to just filter out all unneeded code on build?

I think both are valid solutions. Filtering the addon tree on build would be easier for you, i guess.

FYI: I already added a very very basic partial implementation of this RFC in #128. If you want, take a look at it and give us your feedback!

Thanks, I'll try to take a look and add feedback

[makepanic]

Great idea!

A random thought from my side would be to decouple any css framework compatibility from core.

This has an advantage of others not having to bundle components/styles that aren't needed (similar to other addons which strip module from the addon tree).
ember-validated-form could still ship defaults for any well-known css frameworks.

So something like the following configuration would allow a user to specify which component will be used for any validated-form form field type. This reduces copy pasting when specifying a custom rendering component.

// config/environment.js
...
"ember-validated-form": {
  "render": {
     "text": "validated-input",
     "textarea": "validated-textarea",
     "label": "validated-label",
     "checkbox": "validated-checkbox",
     ...
  }
}
...

One could maybe also allow aliasing so "render": "bootstrap" would tell the addon to bundle the default set of bootstrap form components ("render": "foundation" to bundle foundation components and so on).

This could mean that the developer could still overwrite the renderComponent on a per form field basis but also get custom rendering for the whole project without having to copy paste it all over the place.

I guess one could even combine it to allow default rendering for all form components but overwrite some:

// config/environment.js
"ember-validated-form": {
  "extends": "bootstrap",
  "render": {
     "label": "some-special-label"
     ...
  }
}

It's also possible to not have any magical extension logic but export some objects, which could be Object.assign'd to create the final render configuration:

// config/environment.js
const {bootstrap} = require('ember-validated-form/configs');

"ember-validated-form": {
  "render": Object.assign(bootstrap, {
     "label": "some-special-label"
     ...
  })
}

[anehx]

I think both are valid solutions. Filtering the addon tree on build would be easier for you, i guess.

I think filtering it brings the advantage of not having to maintain x other addons for every existing framework while still decreasing the payload significantly.. Like this, we have all of the ember-validated-form related code in one place.

[makepanic]

I think with lerna or yarn workspaces there wouldn't be much additional maintenance overhead while still having all ember-validated-form code in one repo.

With filtering you also have to maintain additional broccoli code that filters the addon tree.

But it's up to you for what's easier to maintain.

[anehx]

Well, we'd still have to maintain all of the dependencies for every addon even if we have it in one repo.. Or did I miss something?

[czosel]

I'll go ahead and close this since the redesign has landed since a while 🙂