Intent to RFC: Deprecate Computed Properties

[pzuraq]

• Proposed Target: Ember v5.0.0
• Alternative: Tracked Properties, macro-decorators

Computed properties have been an Ember mainstay since the beginning of the framework. They were how Ember accomplished reactivity, and they have been incredibly useful for deriving state in a declarative way. Tracked properties iterate on CPs, giving us the same benefits with less boilerplate and more flexibility. CPs add a large amount of complexity to the framework overall, and a hefty chunk of code, so removing them will be a major win from a maintenance perspective and a bundle size perspective.

Migration Path

For the most part, migrations from CPs to TPs should be pretty straightforward. There will be gotchas, particularly around caching since getters for TPs do not cache. We should make sure we have lots of guides showing users how to migrate, and how to debug tracked properties (especially in cases of infinite rerenders/invalidations).

Part of deprecating CPs also includes deprecating CP macros, such as @and(), @or(), @filter(), @alias, etc. These macros were very useful prior to TPs because they allowed users to avoid a large amount of boilerplate, but since the boilerplate has been reduced so much with TPs, they may not make much sense in most cases anymore. They also represent a fair amount of bundle size, and a decent maintenance burden.

This pre-RFC proposes that Ember should not continue to provide computed property macros. Since any getter should work with tracked properties, users can instead rely on a generic decorator libraries, like macro-decorators. These libraries don't need to be Ember specific, or maintained by the Ember core team, and can instead be community driven. This would also allow them to experiment much more (similar to ember-macro-helpers), without relying on private APIs or causing additional issues down line since it's Just JavaScript™️.

Deprecation Timeline

Computed properties are highly prolific in Ember code today, so it will take quite some time for users to migrate from them. This is why this pre-RFC proposes that we deprecate them for removal in v5.0.0, which should give the community plenty of time to adopt the new idioms and migrate away from CPs.

[chriskrycho]

Depending on the timelines, we might be able to make these an optional feature installed by default at a 4.0.0 release; alternatively, we should aim to take advantage of the various tree-shaking/svelte-ing approaches outlined in #532. Either way, we should ensure that if people are able to switch entirely, they stop paying for these in bundle size.

[pzuraq]

Yup! That’s the point of svelte flags, definitely 😄 They give us a standardized way for users to opt out of large deprecated features, so we don’t need to worry about the details for each deprecation RFC

[jrjohnson]

My comment is that it is too soon to give comments on this. Until I'm able to migrate to all the octane stuff in my app I just don't know yet if there are still uses for computed properties, if the new programming model holds up, etc. I'm worried this may go the same was as proposing the deprecation of controllers i.e. adding a lot of questions for new users, but not actually being possible because of deep underlying complexity in removing them.

[pzuraq]

Totally understand the hesitance, especially since we have previously tried to push forward as a community without fully replacing a concept (like with Controllers and Query Params). I do think computed properties are different for two reasons:

1. CPs are a much simpler concept overall. They are responsible for two things - change tracking/propagation, and memoization/caching. The former is what tracked properties are all about, and the later is something that can be added on top of tracked properties manually, or with public APIs for autotracking once those are available. I would like to add @memo or something like it in the near future, but computationally expensive CPs are more uncommon, so writing manual memoization logic when needed for optimizations should be possible, and not unacceptably unergonomic (IMO)

   The main point here is, unlike Controllers and other major Ember concepts, CPs have a very well defined, very tightly contained public API and set of concerns that they address, and we're pretty confident that TPs cover the same use cases.

2. The other reason we're pretty confident of this is that as of Ember 3.13, CPs are effectively syntactic sugar on top of TPs 😄 in order to make sure the two systems interoperate, we actually had to rewrite CPs to use TPs under the hood. So, CPs are really just a more complicated version of TPs at this point, with caching-by-default.

Between these two points, I'm personally pretty confident that all use cases for CPs have been covered. There's a reason why the deprecation period here is 2 major versions in the future though, which is to give us time in case we do encounter issues or missing use cases along the way.

[lvegerano]

I'm all about this deprecation RFCs. My question is about the target, why v5? Is it necessary to keep compatibility/bloat until then?

[NullVoxPopuli]

I think mostly because for many long-lived apps, deprecating in v4 is too aggressive a timeline. deprecating for removal in v5 gives all the apps that have been in development since 8 years ago time to catch up.

Also, I believe there is work happening to allow you to opt in to deprecated features to be removed, since you (and me) like to stay ahead of / on the curve / edge. :)

[chriskrycho]

It depends on the timeline for 4.0. If 4.0 is in three months, yeah, it's too aggressive. If it's sometime in 2021, well… probably not. 😆 This is definitely a pre-RFC for that reason.

[wagenet]

Despite this being inactive, it seems important enough that I'm going to leave it open. We should find a way to fast-track the generation of RFCs for this type of deprecation.

[chriskrycho]

Agreed. It’ll be covered in the output of #832, but as with observers we can split it out if that proves expedient.