Seems to be broken with ember-source >= 3.21.2 and [email protected]

[BnitoBzh]

After upgrading EB to its version 4.2.0.
I get this error You attempted to use @dependentKeyCompat on a property that already has been decorated with either @computed or @tracked....
After a little debug it comes from the class BsFormElementWithChangesetValidationsSupport with the errors getter.

[BnitoBzh]

emberjs/ember.js@57a2044

[danieledraganti]

Same problem, obviously, on Ember 3.22.0. Removing @dependentKeyCompat from element.js fixes the error but removes listeners to update the form when an error is triggered.
Can this be fixed in the add-on, or do we need to wait for the core Ember team to decide what to do with this assertion?

[jelhan]

Can this be fixed in the add-on

To be honest: I don't know. Due to current validation plugin API used by Ember Bootstrap we need to use a computed property. But Ember Changeset Validations using a tracked property. It's only working together if @dependentKeyCompat is used as far as I know.

But Ember Bootstrap uses its @defaultValue decorator on that property: https://github.com/kaliber5/ember-bootstrap/blob/50937097944ad7c8a0504088628fc1972606bea4/addon/components/bs-form/element.js#L382-L383 The @defaultValue decorator is implemented using a computed property: https://github.com/kaliber5/ember-bootstrap/blob/master/addon/utils/default-decorator.js

do we need to wait for the core Ember team to decide what to do with this assertion?

I don't think the assertion will go away. As far as I got it it's technically correct. Using @dependentKeyCompat and computed decorators together on the same property can cause bugs. At least that's what I got from the commit linked by BnitoBzh.

The only solution I see so far is to change Ember Bootstrap. It's already planned to rewrite <Form::element> component to extend @glimmer/component and use tracked properties. This would remove the need of @dependentKeyCompat on our side.

But I'm not sure if anyone researched yet if the current validation plugin API is compatible with @glimmer/component. If so doing that rewrite seems to be the best solution for this bug.

[danieledraganti]

I would guess that decorators ARE contained somewhere in the class definition. I couldn't find any information, though. The idea is: if we "reset" the errors property to not be computed anymore, then we should be able to set the @dependentKeyCompat again without getting the assertion. Maybe if we extend the original BsFormElement and delete this.errors in the constructor(), and then extend the BsFormElementWithChangesetValidationsSupport from this "intermediate" class?
Yes, it would be a very, very ugly workaround, but maybe it'll work in the meantime...

[jelhan]

That might work indeed. @danieledraganti Do you have time to try it out?

[danieledraganti]

@jelhan Sure, will try it today or tomorrow and make a pull request in case it works.

[danieledraganti]

I tried the following:

class NoErrorsBsFormElement extends BsFormElement {
  '__ember-bootstrap_subclass' = true;
  constructor() {
    super(...arguments);
    delete this.errors;
  }
}

... and then extending BsFormElementWithChangesetValidationsSupport from the newly-generated class. Assertion still triggers.
I believe the tracked or computed status of the property is saved somewhere else in the class... does anyone here with knowledge of the inner workings in Ember have an idea of where that may be?

[jelhan]

I believe the tracked or computed status of the property is saved somewhere else in the class... does anyone here with knowledge of the inner workings in Ember have an idea of where that may be?

If I recall correctly computed properties are registered on the prototype not on the class instance. So maybe we need to delete BsFormElement.prototype.errors instead of delete this.errors?

[jelhan]

The assertion has been backported to latest LTS in 3.20.6 version. As this now affects current LTS it has a higher priority in my perspective.

[jelhan]

I finished the @glimmer/component and tracked properties refactoring of <BsForm::Element>: ember-bootstrap/ember-bootstrap#1339 As soon as that one is in and released we need to do some changes on our side. I prepared the required changes in #34. I hope that we have a version out with a fix soon.

[lindyhopchris]

Looks like the assertion has now been removed:
emberjs/ember.js#19263

That was tagged as 3.22.2. Haven't had a chance to give it a go yet - this issue was blocking me upgrading.

[danieledraganti]

Great news!

[lindyhopchris]

I'm seeing this as fixed in 3.22.2, but getting the same error on 3.23.1, which isn't great news.

[jelhan]

It's fixed by #34. Just pending for Ember Bootstrap release. Will ask @simonihmig if we can do a release of Ember Bootstrap soon.

[jelhan]

Should be fixed in [email protected] released today. Please note that it's only compatible with ember-bootstrap@^v4.5 released a yesterday.