IV. ConclusionClient-Side Architecture
This is page four of a guide on Client-Side Architecture basics. Start at page one.
The work isn't over
I know this article expressed a lot of new ideas. To be completely honest, I spent about three months thinking about this off and on, and I'm likely going to spend some time revising it and trying these ideas out with real-world projects.
Stay tuned for updates on this. If you subscribe to the newsletter, I'll let you know when I publish major updates.
Let's look at what we've covered.
A new client-side development philosophy
Zooming out, we started with this:
And then zooming in, we landed on this:
Let's recap the statements I've made.
Model-View-Presenter isn't good enough for our needs anymore
The problems we're solving on the client-side are much more complex than they were 20 years ago. Because of that, the starting point for an architecture probably can't be MVP.
Design principles have persisted for a long time to help us write better software
I honestly think that reading books and learning from the past is one of the best ways to avoid future mistakes. Design principles are great. You don't need to always follow them, but know the rules before deciding whether you want to break 'em.
There are no silver bullets
There really aren't. With this advanced client-side architecture, what we introduce in structural quality, we lose in developer experience based on the potential learning curve involved. But ask yourself this question: is the complexity related to nature of the problem itself, or is it just related to the way we're solving it?
This is for developers where "use what works for you" is daunting, and would like a good conceptual starting point for an air tight React architecture
I'm really excited about these ideas. I've been milling around with this for a couple of months now but I think it's really important today. If you're a developer that has been told to use "what works for you", that's still incredibly good advice. But if you run into any of the pain-points in your React project like suddenly facing issues adding features, changing code, and feeling like things have turned to mush, this might help.
We shouldn't stop here. Here are a few thoughts to chew on. Feel free to ask questions and leave suggestions on ways I can make this guide more helpful.
Choosing a stack: Given this philosophy, what factors into deciding upon a stack? Compatibility? Developer experience? Maintainer(s) activity?
Organizing code: How do you organize code within a React project? What principles are at play?
Dealing with prop drilling: If we have these clear-cut layers, doesn't that mean we'll have to do a lot of prop drilling?
Test-Driven Development: Can we discuss testing in more detail? What does a test-driven approach to client-side application development look like in 2020? Should we write BDD-style acceptance tests with React Testing Library and Jest? Or should invest into testing for functional correctness using E2E tools like Cypress.io?
Real-life project: What does this look like in practice?
Liked this? Sing it loud and proud 👨🎤.
Stay in touch!
Enjoying so far? Join 15000+ Software Essentialists getting my posts delivered straight to your inbox each week. I won't spam ya. 🖖
View more in Client-Side Architecture
You may also enjoy...
A few more related articles
Want to be notified when new content comes out?
Join 15000+ other Software Essentialists learning how to master The Essentials of software design and architecture.
Commenting has been disabled for now. To ask questions and discuss this post, join the community.
Hi, this series of posts are really great. I have been thinking how to change our code base to be testable/maintainable. Sadly it’s not React but your posts inspired me a lot.
I will make some proposals and share with the team shortly.
thank you so much!
I wonder how could be a real life app using this architecture.
Hi Khalil, the past months I've been struggling and squeezing my head around how to apply a clean architecture to the front-end, I really want to say THANK YOU, you are definitely connecting all the dots of my mental graph, not only with this serie, with your whole blog.
Wonderful. Here goes another piece of internet gold.
Solid advice here, keep these coming!
I tried to follow the clean architecture principles in this project. https://stackblitz.com/edit/vitejs-vite-p8voy6
The codebase is relatively small. My main concern is how things will play in a larger one with lots of interconnected dependencies.
Awesome content. Would be awesome to see this architecture in a real app structure. Thanks for the content, Khalil!
Thank you for the article. It was very interesting to read. But I have a concern regarding that approach: you suggested keeping the page root component as a Presenter component that glues the model to the view. That means that if a part of the global state was changed, then all the page components will be re-rendered (as they are children of the presenter component). Or you have to implement the memoization logic, what can be avoided if you keep state closer to the UI that renders it.