Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validation on model versus component #684

Open
ghost opened this issue Sep 15, 2020 · 1 comment
Open

Validation on model versus component #684

ghost opened this issue Sep 15, 2020 · 1 comment

Comments

@ghost
Copy link

ghost commented Sep 15, 2020

Is there any preferred pattern when it comes defining validations on an Ember component versus an Ember Data Model?

@schorke
Copy link

schorke commented Sep 17, 2020

I'm facing exactly the same dilemma. I think there're pros & cons in both approaches.

Model

Pros

  • Defined in one place, next to where model is defined. This means that validation can be done anywhere as long as you have your model.

Cons

  • The whole model object needs to be passed to form component in order to do the validations. I tend to avoid passing large object to component and only pass what is necessary to component instead, property by property.
  • When testing component, need to create (in the test) & pass the whole object containing validations.

Component

Pros

  • This is where validation is done (I don't personally use validations in any other place than forms), so this seems like the right place to place validations.
  • Easier integration test => no need to manually add validations to your model when passing it to component, because validations is built-in your component.

Cons

  • In Ember Octane, cannot add the validations to a Glimmer component like it was done on Ember component via the Component.extend(MyValidations);.
  • You have to add the validation on each component that needs it (instead of having it in one place in the model).

I don't know when ember-cp-validations is gonna be Ember Octane friendly, and I don't know which approach is the best to this day (if there's one). I'm curious to have other opinions on this topic !

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

No branches or pull requests

1 participant