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

Issue deprecations for tracked mutation in constructor during rendering #19284

Merged
merged 2 commits into from
Nov 23, 2020

Conversation

rwjblue
Copy link
Member

@rwjblue rwjblue commented Nov 23, 2020

Backport changes from #19282 (see that PR for more details) to beta (requires a custom GlimmerVM release).

Fixes #19192 in 3.24

Includes the following bugfixes:

* [#1209](glimmerjs/glimmer-vm#1209) Ensure
  `<output form="some-value">` works properly
* [#1205](glimmerjs/glimmer-vm#1205) Ensure
  `@tracked` assertion can be made a deprecation

Changelog here:

https://github.com/glimmerjs/glimmer-vm/releases/tag/v0.65.1
…endering

During recent refactors that landed in glimmer-vm@0.57 (Glimmer VM
version that landed in Ember 3.22) we moved the internal infrastructure
to ensure **everything** was in a tracking frame. This greatly increased
the number of locations that would now fall under the standard read +
write assertions.

For example, in glimmer-vm@0.56 the following would run without error:

```js
import Component from '@glimmer/component';
import { tracked } from '@glimmer/tracking';

export default class extends Component {
  @Tracked counter = 0;

    constructor() {
      super(...arguments);

      this.counter++;
    }
}
```

Now, obviously this is a bit contrived, but the point is that since
component construction was not previously within a tracking frame it
would **not** error due to the read then write of a tracked property.

As of glimmer-vm@0.60+ we **do** run this within a tracking frame
(because nearly everything is automatically within a tracking frame).

---

This change ensures that the (previously untracked) construction of
components, modifiers, and helpers trigger a deprecation **not** an
assertion when mutating a previously read value within the constructor.

(cherry picked from commit 3a613d6)
@rwjblue rwjblue merged commit 8ddb5a7 into beta Nov 23, 2020
@rwjblue rwjblue deleted the beta-tracked-mutation-in-constructor branch November 23, 2020 18:38
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

Successfully merging this pull request may close these issues.

1 participant