[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.