Decoupling UI Components: Addressing Layout and Dependency Challenges

[Phạm Đức Mạnh]

I recently watched John Ousterhout's talk on Decoupling at Talks at Google, where he highlighted its significance in computer science. In the backend (for web apps, for instance), we often decouple data processing flows, split tasks into smaller functions, and merge them while ensuring integrity and optimization. But how does this apply to the frontend, especially UI development?

Libraries like SwiftUI, Flutter, and Jetpack Compose seem to promote a functional programming approach, making it easy to declare and separate views/widgets/compositions. 

However, in practice, I have noticed that it’s not usually simple because UI space is finite, and often views cannot fully function independently from their parent or surrounding views. They need to be aware of layout constraints, whether the parent is scrollable, or they risk UI overflow + misalignment.

How can we address these challenges in UI design while maintaining a functional, decoupled approach? I’d appreciate your thoughts and some helpful keywords.

Thank you !

[David Hess]

I believe UI’s are unique in that they are extremely stateful – which makes it nearly impossible to apply a pure functional approach to them.

However, you can apply object-oriented techniques to organizing, managing and hiding all of this state. Roll your individual UI elements up into something like a View / Dialog level of abstraction and treat them like an object class. You can instantiate them, they are responsible for managing the elements physically contained within them, and they should provide a simple and information hiding interface to anything else that needs to communicate with it.

So for instance, if you have a form of UI elements that displays in a dialog, I would subclass whatever goes for a Dialog class in your UI environment. It would manage both the construction and display of all of the child UI elements within it. It would implement any needed form validation logic. It would also present a simple exterior API to display the dialog and then retrieve the entire form contents from it upon completion of the form.

The exact details of how to accomplish that will vary in different UI runtime environments, but I’ve found that general approach to work well in any of them.

Dave

--
You received this message because you are subscribed to the Google Groups "software-design-book" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software-design-...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/software-design-book/3d4dedbd-ef79-4b33-8e96-785076d7c7d7n%40googlegroups.com.

[Phạm Đức Mạnh]

Thank you again, Dave  

I’d like to share a reflection and follow-up thought:

In the past, I primarily worked with UI frameworks like JavaFX and mobile SDKs where object-oriented programming dominated. State was implicit — you interacted directly with views and controllers, and in my opinion, the state management often felt "invisible."

However, in newer declarative technologies like SwiftUI or Flutter, state management takes center stage. The UI instructions tend to becomes a pure function of state, and since views themselves are immutable declarations, the only mutable part left is the state they respond to. This shift made me realize: managing state becomes a form of managing side effects — just like in functional programming.

In this context, I found the rise of hooks (React, flutter_hooks) or effect systems (algebraic effects) quite fascinating (thought I admit I haven’t fully grasped their underlying principles yet).

But even then, I’ve noticed that state management mostly applies to data-bound logic. When it comes to non-data context, such as:

• Responsive layout
• Adaptive behavior    
• Routing 

It still feels hard to fully isolate those effects. These parts tend to bleed across components and force some degree of coupling or branching logic.

In practice, I often see teams just split the whole app by platform (web vs. mobile vs. desktop) and handle layout adaptivity independently within each project. But this feels less composable — and not ideal if we want a shared system across platforms.

I wonder if there are any UI patterns that allow child views to be "oblivious" to their platform, layout, or parent context — and yet still behave appropriately when composed into different containers ?

That is, how can we let parent views opt-in to control or constrain their children, without the children needing to understand their host environment ?

Thanks again for inspiring this line of thought — writing this helped clarify a lot of my own confusion too. I'd love to hear thoughts from others who’ve wrestled with these same concerns.

Still, I believe statefulness and side effects are inevitable; my aspiration is to find better ways to contain and isolate them — however hard it may be today, I see great potential. This belief stems from the idea that functional and structured programming are fundamentally equivalent in power, and in practice, pure functions tend to help developers avoid many common pitfalls.