Tracked Properties Updates

[pzuraq]

Rendered

[jonnii]

It's arguable that computed properties that are relying on these caching semantics are problematic in general. After all, it's strange to setup state like this during construction, usually you would use a CP instead, and if CPs are trying to use a value, it generally means that value should be a dependency.

I understand what's happening here but my issue with the fix is it seems like it requires you to put the @watchable attribute on the class which is doing the right thing. If the behavior is fixed there would be no feedback that this attribute is now no longer required. Perhaps using @watchable should also come with a deprecation warning or a linting hint to encourage changing the flow to be a cp/dependency and/or migrate to native classes?

[pzuraq]

We tend to do deprecations as separate RFCs from introducing new features. Computed properties aren't officially deprecated yet, though they likely will be sometime in the future. Until then, I don't think we should provide a deprecation warning for users of computed.

A linting rule may make more sense here. There is precedent with the "avoid-observers" eslint rules, for instance. I don't believe we need an RFC to create a rule like that though.

[rwjblue]

I don't believe we need an RFC to create a rule like that though

Agree, we can create the rule without any RFC type things. We'd only need to RFC enabling it by default.

[MelSumner]

Since this is important to the interop story, we've decided to move this into FCP.

[luxzeitlos]

Basically a @tracked is always @watchable, right? Why would I then ever need to use @watchable and not @tracked?
From my perspective @tracked does no harm if used too much, right?

[pzuraq]

@tracked cannot and should not be used on native getters and setters. In the long run, all getters and setters should be native, without any decoration.

@watchable can only be used on native getters and setters, by contrast. It is only for compatibility, and eventually should be removed.

If we made @tracked work on both, it would quickly get confusing - users might think they need to mark everything as @tracked, which they do not, and they will find it much harder to quickly search for code that should be updated and refactored.

[hjdivad]

Missing a third case: manual proxies that implement unknownProperty and setUnknownProperty

[mixonic]

As we've discussed a @classic decorator in RFC 468 and this is also viewed as a somewhat temporary compatibility/migration path item, I'll float @classicDependency