Client-Side Architecture Basics [Guide]

This is a really great article, might need to come back later when Im not so overloaded with info also I want to give my two cents in the prop drilling part and the organising code, most of it can be solved with composition, it helped me tremendously in refactoring a lot of stuff that was so tightly coupled and also repeated across several react native screens.

Now you can just have really small components that only care about showing something and then "higher" components that define the layout and only pass its children. That way you can pass a lot of props without making the layout ones caring about those, they only care about the children they have inside and how to style them properly. For example, like a reusable table, you have a component for the rows, that only cares about how many children you send in as columns, they could all end up being different dumb components you created for lets say, main info, and generic info, main info in the case of the project Im on, has a button that triggers an Apollo mutation to start following or to stop following that entry, and a text with the main ID. Said button is another dumb component that just passes the type of graphql model that called it along with the ID, so the mutation is executed elsewhere. Before that that logic was shared across several screens, it was not sane whenever changes where implemented, so refactoring it that way along with composition made it much more manageable and now I only have to care about a single file for it.

Still from this article it seems I can even go even further, sadly Im still not so good with hooks so I end up using a class based component for the main screens/pages that are in charge of organizing and styling the layout to show, and all the components they call for it are just functional components.

A question though, when looking through state management I came across a few articles from Dan saying to basically, if you can keep the state in the component, just do that instead of trying to go plus ultra and sending everything to redux. In this case, if you have a single piece of logic that you know doesn't need to be shared across several pages/screens etc. would implementing the state locally would go against this architecture?

Hey, great post! thanks for this. What about MobX for state management ? I use it and I think it's a very great choice...

Awesome article as always, learned a ton. Thanks.

This is fantastic! It's been difficult to find good advice structuring medium-sized frontend applications, but this is exactly what I needed. Our stack is Vue (and REST instead of GraphQL) but the concepts translate pretty easily with a little thought. I don't think it's an exaggeration to say that if the concept of UI-as-pure-function defined the past few years of my frontend skill development, these insights into state management will define the next few years.

Great article! I have a question about using pages as containers https://khalilstemmler.com/articles/client-side-architecture/introduction/#Container-components-are-pages. Is it possible to have simple relation pages/container => Section<view components>? Most of time I ended with more nested architecture and if there is more nesting then passing all those props is nightmare. Also if we have simple relation pages/container => Section<view components> then Section component, which holds all view components, will be a huge one. As it would have to manage all those view components. Maybe you suggest some article about it? Or you can share your knowledge :)

Fantastic article! Answered a lot of the questions I had but didn't quite know how to frame.

I just want to say thanks. great job!

Would it be possible to build frontend apps that are framework-agnostic ? i.e. the way clean architecture lets you push frameworks to the edge so that they can be easily swapped out if the need arises

Great post! Thank you!

I really appreciate you taking the time to share your thoughts with such helpful illustrative examples. You're a gift to the community. Thanks so much.

A very nice guide. I will definitely follow these tips. Thank you for sharing such detailed article. I am learning a lot from you.

https://nareshit.com/reactjs-online-training/

Is the complexity related to nature of the problem itself, or is it just related to the way we're solving it?

Having worked on several large SPA apps over the last 4 years, in general they scream accidental rather than essential complexity IMO. There's a pretty tremendous increase in logic on the client compared to server rendered templates, not worth it in many use cases. Not to mention the initial load / render and SEO hit, which pushes you towards SSR adding even more complexity.

Hi there. I applaud that you have taken the time to think about how to write web apps upfront. Architecture and design do matter. However, I would recommend you to pass your article through an actual architect and see what is his feedback. I read up to a quarter of this and I feel like this should be reviewed by professionals with experience in design and architecture.

C'est magnifique! Merci!

Teste do React

Good one to learn about client side architecture. Will share it in our bootstrap tutorial section.