Modal, The most toxic code paradigm you can write

Modal (or Dialog) in engineering is generally the most toxic piece of code any engineer could write.

Forms are usually stateful, which warrants a lot of useState(), which corrupts performance and is attributed to if conditions. While standalone, they’re self-contained and maintained. Modals are superimposed UI on existing interfaces, which requires mixing “layout” code with “forms”; if you have multiple forms, that’s just layered complexity.

You could probably guess by now these 1+1n together are quite a hellscape to work with/on—creating unnecessary, unwarranted tech debt, as we engineer put it. That’s just for “interactivity code”, for UI positioning, that’s another complex topic on its own. By super-positioning UI on top of another UI, you’re first mixing two distinctly separate concerns together and requiring engineering to understand the parent-child relationship in UI. One could argue that it’s an engineering problem, and it’s an engineer’s job to display good judgment on how to separate concerns and implementation. But that’s a far cry from engineering reality. UI Engineering is unnecessarily complex because we easily assume something looks nice as good engineering implementation—but truly, under the hood, it is a gigantic mess.

Design vs and Engineering

Design and Engineering is a symbiotic relationship that people often forget.

To move as a symbiotic unit, and of course, to move quickly, we need to be upfront about how the product narrative moves. The product, together with the design, can easily change the narrative, delete, add, change, and remove UI—the engineering team is always confined by their inherent abstraction and mountains of technical debt. And when things change and are expected to change, all previously written code is just technical debt waiting to be refactored. Engineering might be eager to don’t repeat yourself (DRY) their code because that’s what all engineers are taught: code polymorphism, code reuse, and performance.

The TLDR is a page is “self-contained”, modals are usually “contained within a page/layout”, and having a sub-screen on top of an existing screen is what we call “spaghetti code”.

But if we make a page and then have the page serve as a modal, you force the engineer to consider that their modal is self-contained. This changes the “game” so the speak, because you force the engineer to separate concerns.

Deep Linking

When you click on Modal, you will open a dialog. Your URL should be changed from /orgs to /orgs/create giving you permanent deep linking. This allows the modal to popup with a backdrop-blur-sm hiding the content it’s overshadowing. This is implemented automagically in code without creating technical debt.

When you refresh the page while at /orgs/create the dialog will collapse into a full page experience. Allowing you to transition from modal into a page. To achieve this, all Modals are essentially a page with different frame (think viewport). Hence, we should work on “pages” first, and then decide whether to have the modal experience later. To caveat here is that all Forms must be responsive and easily transition in modal/page vice versa.

It’s not about discouraging the use of Modal. The modals just have to be done properly, as a page, before they even make sense to be “superimposed.” Even a simple modal that is small and center-ly placed is better for engineering than not-well-thought out Modal/Dialog.

That being said, these confirmation (without an input) Modal is another story—those are perfectly fine, we don’t need a page for it.