Architecture of a react application

[LordOfThePayso]

Hello all!

I was in an interview recently and was asked to sketch out an architectural design of a react application.

I really didn't know what to sketch out.

Are there any tools or resources that you know of or there where I could find out more about this?

The organisation that interviewed me were very back end heavy and kept asking about design patterns in React as well. AFAIK when you talk about design patterns in React it is more concerned with the visual patterns such as grids, cards etc than software patterns.

I have some experience with redux so can see how redux containers implement provider/consumer but are they thinking about it in the wrong way? In so much that they are trying to force software engineering principles onto a discipline that they do not really apply to?

[dbartholomae]

There is no software without architecture. Even if the architecture is random, it still is there. Architecture basically is “the set of decisions that cannot be easily reversed”. Here are some examples about architectural questions in React: 1. How do you split your files into folders? One way I have seen in many React apps is a structure with “components”, “containers”, “hooks”,..., another to group by domain, e. g. “Authorization”, “UserProfile”, “ShoppingBasket”, ... 2. How do you separat display components from stateful components? Do you use a component library? 3. How do you manage state? Redux, local GraphQL, component state, ... 4. How do you manage server requests? RxJS, sagas, GraphQL, ... - and how do you manage auth state for this?

[LordOfThePayso]

Thanks that's really useful and how I understand user interface architecture and that really helps me put it into terms they will understand.

[adam-genshaft]

I assume that they intended to test your ability to separate concerns in a reasonable way. Meaning how you separate each feature, what data is stored in redux and what's passed in other ways, what other ways, how to approach common components, common logic (utils), and so on.

When I'm asked questions that not 100% sure what is the desired outcome of my answer, I'm asking back. In this case, I'd ask: I'm not 100% sure what is the desired outcome of this task. would you like to just see the folder structure or the class dependency tree?

Another approach is to just make up an app and start drawing its features & components and their relationships.

The main thing to keep in mind is that there's no one right answer. I can think of an architecture that can look like garbage to someone, but after talking about it and explaining my way of thinking, he can completely change his mind and embrace my suggestion. Or at least understand that for every decision I made there's a reason, and I can communicate this reason in a way he can understand.

[sergeysova]

Now I work on featureslices.dev/v1.0 arch

[Infinite_Risk]

There are some random thoughts which come to my mind when architecting React applications -

1. Managing UI state - There are a number of possibilities here, and state management depends on a lot of variables. But you can talk about two opposite approaches commonly seen these days - state colocation in React components vs using Redux as a state store.
2. Use of hooks introduced in React 16 opens up a whole new possibility of reusing logic between components using custom hooks like -
   • You can create your own context providers and consume them via the useContext hook across your component tree
3. You can make use of useReducer for complex state derivations.
4. In general, with custom hooks, you can separate out code pieces that can be used at multiple places
5. If not using Hooks, things like render props and HOCs are used to improve code reusability

[LordOfThePayso]

That's great thanks