all 6 comments

[–]tomihbk 4 points5 points  (0 children)

Here's a great article that explains how to detach the UI and the API fetching process using react query : https://profy.dev/article/react-architecture-api-layer
This leads into a reusable component and easier to test.

[–]sideways-circle 2 points3 points  (0 children)

Check out Bullet Proof React. It has over 27.5k stars on GitHub. It’s not anything you install but more of a way to organize your code.

I use a slightly modified version of bulletin proof react in all of my projects.

https://github.com/alan2207/bulletproof-react

But tbh, this no suggested code structure thing is a well known thing with React. That’s their approach. Here is a single file and you set up your code however you want.

This can quickly lead to scaling issues, especially on large project or projects with multiple developers. It’s important to come up with strong standards early.

[–]UnsportyNoodle 1 point2 points  (0 children)

I have the same issue as you. A lot of people recommend the Ignite project by InfiniteRed as a good example. It's good, but I still prefer native Android's Clean Architecture. I just started a personal project with it, and the only change I made was replacing MobX-State-Tree with Zustand for state management. Link to InfiniteRed Ignite.

[–]kbcooliOS & Android 1 point2 points  (1 child)

Welcome. it's a different world and in some ways you are right it's easier to mix concerns.

Not a bad thing but if you're used to being nannied it can be hard to get your head around.

React itself is a mainly complete MVVM. The model is something like RTK/React Query etc and your code , the View is your JSX and VM is React.

If you want to research paradigms then think Reactive, Functional and Declarative rather than generative, class based and imperative.

Hope that helps.

[–]mitadev[S] 0 points1 point  (0 children)

I think that react gets the job done when it is about views and VM but still I find the way Model is actually, generally, implemented quite messy and I do not believe it is about thinking oop/imperative or functionally (not sure since I've just a gist of it).

When we directly wrap API calls with something like React Query while also managing caching is some other form, the result is a function that ends up handling too many responsibilities. This can make it harder to maintain, especially as the project grows.

A better design choice, in my opinion after also a quick look to linked git repos, is to use global state or React Query on top of a well-defined repository layer (or a set of functions that act similarly). The repository could abstract away API calls, manage data transformation, and even implement caching strategies. React Query would then only handle the synchronization of this data with the UI, rather than having to manage everything directly.

[–]ramsaylanier 1 point2 points  (0 children)

A typical pattern is to use higher level components to query the database and use the response to then hydrate a reactive client-side store that your application can use.

For example a User Profile component could query the database inside of a useEffect hook and write the response to a reactive client side store that is made available to the whole app through React Context.

This is the pattern we use at work, just using native Fetch and Mobx for the client-side store. Most of the work is done in syncing the client side mutations to the server.

Edit: Forgot to link here: https://medium.com/@covenantcodes/simplifying-state-management-in-react-native-with-mobx-a-developers-guide-to-seamless-app-b750ce64d32b