-
Notifications
You must be signed in to change notification settings - Fork 12
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use ember-stargate for Portals? #108
Comments
Wrapping ember-stargate is certainly worth it! (Only reason I didn't use it initially is because i was still prototyping out concepts). Very happy to adopt a robust implementation! I'd even take a pr for it! |
ember-stargate probably resolves: #91 |
looks like this logic in ember-stargate:
would need to be updated to find the "nearest portal target"? This is what allows layering of targets (popovers with tooltips nested in modals with tooltips, for example)
An argument would be passed here: https://github.com/universal-ember/ember-primitives/blob/main/ember-primitives/src/components/portal.gts#L15
this is quite nice tho |
Yeah, this is interesting indeed! Not sure if that's really viable with the approach used in stargate, as targets are registered on a service, and not found by traversing the DOM... 馃
How would you render the (custom) target? Not use |
you got it
I guess, but is an attribute really a big deal? |
Shamelessly wondering whether you have considered using ember-stargate as the implementation for portals? 馃榾 And if so, is there anything that you miss?
Except for code reuse in general, I would see these benefits...
This library (and another similar private implementation we both have seen) makes assumption about the possible targets (popover, tooltip, modal), but what if you have use cases beyond that?
One case I had (which sparked the creation of that addon) was rendering into a navigation/footer bar, that is owned by the parent route (stable component invocation even when switching between sub routes) from the subroute (think of back/next buttons, or some status indicators). The footer stuff depends on the state of the subroute, but the UI layout would require the footer to be part of the parent route (or
application
). This would call for arbitrary portal targets, and the ability to put them separately in arbitrary spots (not just top-level DOM).The low-level
in-element
requires the target to be already in the DOM, otherwise it throws. And I believe (have not tested tbh) the implementation here propagates this behavior, asfindNearestTarget
would also throw when it does not find the target (yet).But what if it just happens (because of the UI structure, think again of a footer element), that the target is getting rendered after the portal? (even in the same render cycle, just "bad" timing)
Like this test would not work, if you would render
<PortalTargets>
after<Portal>
, would it?ember-stargate abstracts this away, see these tests for example.
The text was updated successfully, but these errors were encountered: