Make `captureRenderTree` API public about rfcs HOT 4 OPEN

I think people get scare of low-level RFCs, sometimes 🙃
having better error / deprecation reporting would be a huge win tho

from rfcs.

out of curiosity, is this related to #778

from rfcs.

The main reason I opened the issue is not related to that PR – I was trying to revive emberjs/ember.js#19069 by @bekzod, however I realized a lot of what made it hard/tricky at the time is to still keep some of the existing private "view utils" functions (getChildViews, etc) working. These functions were originally intended for Ember Inspector, but it doesn't use them anymore since we switched to the newer captureRenderTree() API.

Those functions are not really useful anymore since they only work for classic Ember.Component subclasses. So I set out to deprecate them first. Since there is not a lot of urgency (which is why it took so long to get my attention – sorry! there just always were something more pressing/immediate), I figured it would be easier to remove these APIs (after the next LTS) together with the view registry (which is what the original PR tried to do), so we could delete everything in one go.

However, usually when we deprecate something we also need to offer an alternative. In this case, captureRenderTree() would be the direct replacement. However, captureRenderTree() is also private, and generally we don't want to direct people to using private APIs. In this case, since it is going from a private API to another private API, and it's unclear that anyone actually uses these (and did not already independently decide to switch to captureRenderTree() on their own), it seems okay. But I figured I should make it clear that if anyone is actually using them are aware of this and we could work together on stabilizing this API.

Now, as for the #778, it's at least tangentially related, in that if captureRenderTree() is a private API, it does not logically make a lot of sense to RFC changes to it – either it is a private API and we are free to make the changes as needed, or that the RFC would also have to propose to stabilize it and make it public. Since the #778 seems to be motivated by Ember Inspector use cases, I think the latter is probably fine, but nevertheless this is a perfectly good venue to discuss those changes even if we don't end up needing to formally merge it.

As for the proposal in #778 itself, initially I had the same questions as @rwjblue which he asked on the thread, and I think I am still not super clear on it after re-reading it. This is already getting super long, so I'll try the rest another time and reply on the other PR directly.

from rfcs.

@chancancode do you think this is worth an RFC? There doesn’t seem to be much uptake here.

from rfcs.