My use case is as follows: I have a dialogue that will

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

I've been pondering the concept of modals lately. @kcgolden or <a class="user-mention

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

Handlebars helper or component that yields inside a specified outlet anywhere in the hierarchy about rfcs HOT 14 CLOSED

emberjs commented on May 15, 2024

Handlebars helper or component that yields inside a specified outlet anywhere in the hierarchy

from rfcs.

Comments (14)

locks commented on May 15, 2024

I really dislike this idea. It breaks the component's isolated nature and can lead to very confusing "bugs" in the application.

from rfcs.

kzgolden-pba commented on May 15, 2024

I believe the fill-outlet, if it even needs to be a component, would need to break that isolated nature in order for this to work. However, the yielded data inside would be in the correct context. This seems a specific enough case to cover with unit tests such that these bugs you speak of are not a factor.

from rfcs.

lukemelia commented on May 15, 2024

It would be wonderful to have an elegant solution to modals in Ember. It is one of the more awkward parts of apps I've worked on. This API seems like a pretty good solution to me.

from rfcs.

ef4 commented on May 15, 2024

@lukemelia check out the API for modals in liquid-fire. We could break it out as a separate thing (not dependent on any animation stuff) if there's interest.

http://ef4.github.io/liquid-fire/#/modals

from rfcs.

mitchlloyd commented on May 15, 2024

I've been pondering the concept of modals lately. @kcgolden or @lukemelia could you tell me why your modals needs to be rendered into a special outlet on the page? I wrote the "cookbook" on this that is in the guides, but now I'm not sure why I opted to render modals into a special outlet. I think I was mislead by the documentation that I read for disconnectOutlet

@kcgolden here is what I propose for your use case. Let me know what you think:

http://emberjs.jsbin.com/cisoko/6/edit

I have a dialogue that will manipulate passed in data
which I want to make into a component
The dialogue would be a triggered by a button
which would open the dialogue in a "modal" outlet which lives at the application level
I would like the button and dialogue to belong to the same component so everything can be self contained and I don't have to do things like create a special action on the route every time I want to use the dialogue/button combo.
This way, I can just insert the component into the template where I want the button to appear, pass in the data and not have to do anything outside of the component.

I think this pattern is more more flexible than what I originally wrote up for the guides:

If you wanted to render different things in a modal you could make the modal-dialog a block component and give it content to render and not even worry about sending in the model.
If you're keen on passing in a model but want a different form inside, you could continue to do so and maybe give it the name of a component to render inside of itself using the component helper.
This pattern allows you to render modals inside of modals

I figure I'm just overlooking something, but I've not been able to think of a good reason that modals need to be rendered into a top level outlet.

If there is a reason that you need your modal in a special outlet then the component & service approach seems like it would work for your use case. That's essentially what @ef4 has implemented in Liquid Fire.

from rfcs.

kzgolden-pba commented on May 15, 2024

@mitchlloyd - I think the main reason my team puts modals into a single outlet at the application level is so modals of a similar priority level can overwrite each other. A user workflow dialogue only displays one at a time, error modals render above that, but only display one at a time as opposed to stacking the modals. We don't stack them in any way.

from rfcs.

mitchlloyd commented on May 15, 2024

@kcgolden I can see how that "overwriting" behavior could be useful for certain use cases. Thanks for the follow up!

from rfcs.

davewasmer commented on May 15, 2024

@mitchlloyd another potential shortcoming of your jsbin's approach, unless I'm missing something (quite possible), is z-index conflicts. If the containing element of the {{modal-dialog}} component is deeply nested, other elements could appear above that modal overlay in the paint order. AFAIK, the only way to ensure a modal overlay appears over everything is to have it be a top-level element (just below <body>) and have a high enough z-index.

from rfcs.

mitchlloyd commented on May 15, 2024

@davewasmer I've never heard of anything quite like the z-index conflicts you're talking about, but I've definitely been surprised by CSS more than a few times :)

My current understanding is that using position: fixed would put things in a new context that sits over other elements that aren't fixed. Also I believe z-index should continue to work no matter how deeply nested something is. One other thing, I'm usually seeing people put their modal outlet / component right above the </body> ending tag.

It might take some JSBin effort to really put this to the test, but one interesting data point is that Boostrap renders their modals right in-line from where they are launched: http://getbootstrap.com/javascript/#modals. It is interesting however that they also first put a 'backdrop' right before the </body> tag. Not sure why that doesn't just go on the modal element.

from rfcs.

davewasmer commented on May 15, 2024

@mitchlloyd I think you are correct that fixed position elements appear over others, but modal overlays aren't always the only fixed elements on the screen.

Here's a JSBin to demonstrate what I mean. It seems that CSS takes a "breadth-first" approach (for lack of a better term) to stacking, but only for elements that "qualify", i.e. position != static and z-index is defined.

In that layout, the only way to guarantee that the .modal-overlay appears over top of everything else is have it be a direct descendent of <body>.

from rfcs.

mitchlloyd commented on May 15, 2024

@davewasmer Wow, thanks for that great JSBin! That CSS looks like a totally valid use case.

I went to see how Bootstrap handled this with their modals and I can reproduce the same issue that you're showing in your JSBin.

Thanks for taking the time to put that together. I learned something here!

from rfcs.

lukemelia commented on May 15, 2024

We have released a solution to this problem in for ember 1.10 and higher. https://github.com/yapplabs/ember-modal-dialog/ The README has more details.

from rfcs.

tim-evans commented on May 15, 2024

I'm calling this feature 'wormholes' after yapp-labs :P, and am using it for https://github.com/paddle8/ember-document-title

from rfcs.

kzgolden-pba commented on May 15, 2024

closing in favor of @lukemelia's comment. Thanks.

from rfcs.

Handlebars helper or component that yields inside a specified outlet anywhere in the hierarchy about rfcs HOT 14 CLOSED

Comments (14)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent