[mattlondon]

"Full screen modal dialog" is just another way of saying "a page" right? So some HTML and you are done?

I am not sure but from the name of the repo I am guessing this is referring to React JavaScript framework which I think is purely "single page application" deal which would explain the limitation of not being able to load a separate page.

Shame we are reimplementing the wheel for such trivial and basic use-cases. Oh well.

[williamdclt]

Not exactly "a page", as with a modal you are not messing with the browser history and you expect to keep the exact state of the page underneath the modal

[djtango]

I'm in two minds here - a set of tools/patterns exist for a reason so this is a useful write-up for the difficulties involved with doing modals. On the other hand, it is always a warning indicator when the browser/hardware is fighting against me.

In this particular case I feel "modal" is an implementation detail - as long as you don't break the UX contracts (i.e. browser history is left unchanged and page state under modal is remembered) does it matter how you achieve the modal-like behaviour?

In this particular case, it could be easier to render the modal using some HTML and/or CSS and hold onto whatever state was underneath - if you're using React, there's no reason to not transition to a different page and either pass the state to the next component OR use something like Redux so you can recall application state.

[TeMPOraL]

> as long as you don't break the UX contracts (i.e. browser history is left unchanged and page state under modal is remembered) does it matter how you achieve the modal-like behaviour?

I feel like the hazard here is that many developers don't know, care about, or care about knowing, the full extent of the UX contract, and as a result implement something that's only halfway there.

My go-to example of this is one of the Java UI toolkit of old, which reimplemented all controls but tried to make them look as if they were native. The end result was a set of controls that kind-of looked like native ones, except they didn't support appropriate context menus and less-known keyboard shortcuts.

[codingdave]

React works well for SPAs, but is not limited to them.

Either way, though, this does feel like an odd problem to be trying to solve. If you already are a JS app, just handle the blur events to stop them from going to another part of your page. The browser will still let them close the page (or the entire browser), but you can control the UX within your own app.

Whether or not that is a good idea is also a valid discussion. Because if you have to go to such lengths to get the UX you want on a mobile device, odds are you are going to end up with a sub-optimal UX, as mobile apps mostly match conventions.

[sebazzz]

In some cases a replacement with window.open/target=_blank in combination with window.opener might be possible (especially if loading an iframe in the modal otherwise). It requires browser sniffing though, if you still want to keep the modal experience on desktop/tablet.

[lucideer]

If this is using React (it's not actually clear from the .md file, the only hint is the parent repo name), then this is very easily solved: replace the page with the modal.

The solutions seem to be trying to solve this for a normal HTML page without changing page, which is a harder problem.

[slow_donkey]

> If this is using React (it's not actually clear from the .md file, the only hint is the parent repo name), then this is very easily solved: replace the page with the modal.

> The solutions seem to be trying to solve this for a normal HTML page without changing page, which is a harder problem.

This is a very good point. In an actual spa there is no reason to overlay the modal rather than create a new route