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

isDirty/isPristine don’t trigger computed property changes #164

Open
PVSAmulya opened this issue Mar 3, 2022 · 1 comment
Open

isDirty/isPristine don’t trigger computed property changes #164

PVSAmulya opened this issue Mar 3, 2022 · 1 comment

Comments

@PVSAmulya
Copy link

After updating ember-changeset-validations from 2.2.1 to 3.16.0, the computed properties that are dependent on changeset.isDirty are not updating when changeset.isDirty changes. This doesn't appear to be an issue for the other computed properties. Properties on the changeset that contain modified values trigger computed properties as expected.

Here is the project that recreates the issue. isDirty/isPristine computed properties do not get triggered. firstName property does get triggered as expected.

Github Link: https://github.com/PVSAmulya/form-project

When using ember-changeset 3.15.0 with ember-changeset-validations 2.2.1 changeset.isDirty computed property works as expected. I debugged this issue to validated-changeset.

There was a similar issue in ember-changeset for isValid/isInvalid that has been resolved.
adopted-ember-addons/ember-changeset#455

Specific comment that is related to isDirty and isPristine on the PR that resolves the above issue.
adopted-ember-addons/ember-changeset#509 (comment)

Screen Shot 2022-03-03 at 1 07 28 PM

@snewcomer
Copy link
Collaborator

@PVSAmulya I pulled down your repo and removing the computeds fixes the issue. There is some lack of compatibility between Ember's old push based vs today's pull based reactivity. We did add the dependentKeyCompat. However, I took a brief look at ember-changeset and validated-changeset and unsure why exactly it isn't working for isDirty or isValid.

I know this solution might not be feasible on a really large project. But generally native getters for many of the use cases would be preferred.

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

2 participants