Cleanup fastboot hooks and misc view cleanup#14361
Merged
Conversation
We should not be using this class directly
We do not allow apps to accessing `this.element` in non-interactive environments, such as FastBoot. This was enforced by not calling hooks that would expose the “element” (which is often not a real DOM element) such as `didInsertElement`. However, since we sometimes run “update” hooks (such as `didUpdateAttrs`) that happen after the element has been set, there is a chance that we would leak the “element” inadvertently. This fixes the issue by making `this.element` a getter that throws in non-interactive mode. To address cases where apps are relying on the current accidental behavior, we added `ViewUtils.getViewElement` as a private (“intimate”) API to forcefully retrieve the “element”. This should balance the need for warning against incidental usage and still provide a workaround for cases where the fake element is needed, such as custom serializations. As always, using private (“intimate”) APIs are strongly discouraged, not fully supported and might not be unreliable. However, we will try our best to keep it around and deprecate between LTS releases before removing it. Note: the main issue here is that the “element” you get back is likely not a real DOM element with an undocumented set of APIs. This core issue is not really addressed here and the supported APIs and internals of the returned object is subject to change.
This is a follow-up to #14233. At the September 2016 core team face-to-face meeting, we discussed and clarified the intended features for life-cycle hooks in non-iterative environments (i.e. FastBoot). We agreed that components on FastBoot should only react to data changes via the `didReceiveAttrs` and `didUpdateAttrs` hooks. (There is also deprecated `didInitAttrs` hook.) The main change is that we have been incorrectly calling `willRender` and `willUpdate` in non-interactive mode so far (at least since we last checked and added the tests). The problem is that `{will,did}Render` and `{will,did}Update` are intended to work as a pair so running one but not the other could introduce unexpected bugs for applications.
The deprecated `Ember.View` has been removed a while ago. The exports in this file is not used anywhere inside the `ember-views` package and also not re-exported from the package index. Contrary to the outdated documentation, we don’t export the `Ember.View` global also, so this is just dead code. I kept the file around for now until we finish migrating the documentation.
chancancode
force-pushed
the
cleanup-fastboot-hooks
branch
from
6fd3130 to
daab186
Compare
Member
|
Thank you @chancancode! |
This was referenced Sep 27, 2016
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #14353