-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
[FEATURE] Add willBecomeVisible & willBecomeHidden event hooks
#12566
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
Conversation
|
All 44 Failing tests exist in master |
|
I'm extremely hesitant to add new APIs around visibility toggling. It seems like the kind of thing Ember should be doing less of, and not building a richer ecosystem around. Addons would be great for features like toggling visibility. |
|
If there is an effort to extract visibility toggling into an addon I am happy to move this PR there; I don't have the bandwidth to spearhead such an effort myself. However, if an effort is not already underway and you plan to push for it to happen, I think it makes sense for the functionality This is as much a bugfix as a feature as far as I'm concerned...because the current code is only a half-implementation of what is necessary. |
There isn't yet. But if this is a feature we want to remove, I don't think adding new APIs for it is the right direction to head. The failures look like JSCS failures fwiw. I just went down a rabbit hole thinking they were from master, but upon coming back out of the hole I don't believe they are on master. Master has some saucelabs failures, that's all. |
|
The only test failures here are from Change the following: /**
* Toggle visibility of the view, firing event hooks before and after the element visibility is changed
* @private
*/To |
|
Hmm ok, thanks @rwjblue. I don't know why I see the same number of test failures on master, then... |
…ty_support` This allows developers to hook into the visibility change before it happens, to mirror the `becameVisible` and `becameHidden` hooks that already exist. Also refactors `notifyBecameVisible` and `notifyBecameHidden` into a single method that takes an event name to trigger on the view and its visible children
|
@mixonic: Ultimately, it's additive and when an addon is built to extract this functionality, this change can come with it. I agree with your sentiment, but unless there is an ongoing plan to execute this extraction now, I don't see the point in holding off on this PR. Better to consolidate this functionality in one place and extract it altogether when that eventually takes place, than to leave it out and then have to remember to go find this closed PR and bring it into the addon at some unknown point in the future. |
yes, visibility concept is from the old sproutcore days... With templates + css this can exist, without all the extra machinery and quirkyness. I suspect it will be entirely gone in 3.0 |
|
I'm not even sure isVisible is something even being considered for angle-bracket/glimmer components, so I expect it to be gone by 3.0. |
|
Can we get an update on this PR? |
|
☔ The latest upstream changes (presumably #13658) made this pull request unmergeable. Please resolve the merge conflicts. |
|
I need to implement custom I would much prefer that the property is simply deprecated, and the existing implementation not touched until it has been removed in 3.0. This way I can use the existing private hooks to create my custom behavior. |
|
This has been opened for a while and most core members that commented here seem clearly not in favor of merging this. If it is so, can we get this closed? Thank you! |
|
Ya, closing this for now. |
This allows developers to hook into the visibility change before it happens, to mirror the
becameVisibleandbecameHiddenhooks that already exist.Also refactors
notifyBecameVisibleandnotifyBecameHiddeninto a single method that takes an event name to trigger on the view and its visible children