Wrong validation results after upgrading to v3

[jelhan]

I see failing tests after upgrading ember-changeset-validations to v3 in ember-bootstrap-changeset-validations due to wrong validation results.

Commit in which the upgrade was done: ember-bootstrap/ember-bootstrap-changeset-validations@f7ff002

TravisCI for that commit: https://travis-ci.org/kaliber5/ember-bootstrap-changeset-validations/jobs/650006769?utm_medium=notification&utm_source=github_status

Test report

not ok 6 Chrome 80.0 - [76 ms] - Integration | Component | bs form element: invalid validation is supported as expected

    ---

        actual: >

            form-control is-valid ember-view

        expected: >

            is-invalid

        stack: >

                at DOMAssertions.hasClass (http://localhost:7357/assets/test-support.js:10088:20)

                at Object._callee2$ (http://localhost:7357/assets/tests.js:136:37)

                at tryCatch (http://localhost:7357/assets/vendor.js:413:40)

                at Generator.invoke [as _invoke] (http://localhost:7357/assets/vendor.js:687:22)

                at Generator.prototype.<computed> [as next] (http://localhost:7357/assets/vendor.js:446:21)

                at asyncGeneratorStep (http://localhost:7357/assets/tests.js:6:105)

        message: >

            input has error class

        negative: >

            false

        browser log: |

    ...

not ok 7 Chrome 80.0 - [136 ms] - Integration | Component | bs form element: more complicated validations

    ---

        actual: >

            form-control is-valid ember-view

        expected: >

            is-invalid

        stack: >

                at DOMAssertions.hasClass (http://localhost:7357/assets/test-support.js:10088:20)

                at Object._callee3$ (http://localhost:7357/assets/tests.js:208:47)

                at tryCatch (http://localhost:7357/assets/vendor.js:413:40)

                at Generator.invoke [as _invoke] (http://localhost:7357/assets/vendor.js:687:22)

                at Generator.prototype.<computed> [as next] (http://localhost:7357/assets/vendor.js:446:21)

                at asyncGeneratorStep (http://localhost:7357/assets/tests.js:6:105)

        message: >

            password does have error when focus out.

        negative: >

            false

        browser log: |

    ...

Tests

1. https://github.com/kaliber5/ember-bootstrap-changeset-validations/blob/f7ff00243e5186a3995c4818c952131b4fe7ff9b/tests/integration/components/bs-form-element-test.js#L60-L83
2. https://github.com/kaliber5/ember-bootstrap-changeset-validations/blob/f7ff00243e5186a3995c4818c952131b4fe7ff9b/tests/integration/components/bs-form-element-test.js#L86-L129

[arenoir]

I believe you are running into this issue adopted-ember-addons/ember-changeset#434

[ohcibi]

I believe you are running into this issue adopted-ember-addons/ember-changeset#434

No. This one is different. The idea of the ember-bootstrap plugin is to create a computed property on the changeset's error.propertyKey.validation key. The problem is that the computer property is not refreshed when error.propertyKey.validation has updated. It seems to be a different issue of ember-changeset or even one of validated-changeset.

[ohcibi]

I belive #143 is related

[jelhan]

Were able to add a failing test: #229

I don't think either #434 nor #143 are related. The failing test uses a POJO. So there aren't any underlying properties that can cause any issue. #143 is very old and this is a regression introduced in v3.

[ohcibi]

@jelhan this is not about underlying properties but the problem that if you define a computed property that is dependent on the .error property of a changeset object, that property won’t get updated when the changeset updates the .error property. It doesn’t matter what the changeset is proxying and what properties that proxied object has.

[jelhan]

A detailed investigation what's going on including a work-a-round could be found here: #229 (comment)

TL;DR: The issue seems to be related to tracked properties. For some reason an invalidation of a tracked property does not cause a derived state to be invalidated.

[snewcomer]

Is it possible we need to integrate dependentKeyCompat in ember-changeset? It seems like that is needed for native getters + computed interop...

https://api.emberjs.com/ember/3.16/functions/@ember%2Fobject%2Fcompat/dependentKeyCompat

If so, I can look at getting something in by the end of the week!

[snewcomer]

closing due to this PR! Thank you all!

ember-bootstrap/ember-bootstrap-changeset-validations#19