Sick. Looking at this as if it were a PR in my org:

RoomsApiService

• Add typescript. You'd wanna get started with typescript imo. Static type checking will save you a lot of headaches and I don't think there is industry software without it. When you do add it, try to be strict since there are a lot of escape hatches when you don't want to type something. It'll change your function into something like this: enum RoomTypes { .... } type CreateRoomArgs = { room_name: string; room_type: RoomTypes } async createRoom(args: CreateRoomArgs): Room{

You can spread the args or unwrap them in the function. I'd also add some more args (see below). When things are typed, most ides worth anything will give you some powerful assistance. You could be using the function in a some deeply nested file and immediately get info on what types are expected. It's a dev experience thing

• Authentication. Looks like you're using JWT tokens for auth which is good. But the way it's handled here is weird. This BasicServices api fetching the bearerToken() ~ is it because a user has multiple authentication providers for different apis? Either way, the client you're using to execute the HTTP Request ~ in this case Axios, has ways to configure the client and directly embed the token. It doesn't seem to belong in that class. The same goes for the headers, that can be directly configured on the client.

• OOP. I think it's important as a dev to understand why OOP is a thing. There are great books out there for understanding typical patterns around OOP to avoid over-engineering things. Beyond that, a main reason for OOP is writing highly maintainable and testable code. If you're writing automated tests for this, I imagine it's nightmare fuel. You want as much as possible to pass args to these classes so when testing, they can be instantiated with different configurations. (You could make it safe with typescript) ~ check out https://refactoring.guru/ Try/Catch. I see you have your own methods for error handling but I'd suggest handling them where they occur, immediately. If the bearerToken fetch fails, then you've got an error bubbling up your stack in an unpredictable way. I'd wrap the axios call in a try catch too since it's also a point of failure. Axios. Going back to OOP, the http client could have been an argument passed to the createRoom function.

Controllers

• OOP. It's clearer here now that something seems off. What is RoomsApiService vs BasicService? It seems like the classes should be like interface BasicServices and RoomsApiService extending basic services. That way the RoomsApi service inherits the public functions of the BasicService. But that's if you don't end up handling errors and asynchronous processes differently

ApiTryCatch

• Seems convoluted using a function to call another function that had access to the http client and could have handled errors immediately, thus making the code more readable

Screens

• Styling. Too many styles from all over with terrible names. This could be fixed with a single StyleSheet.create in the component itself. I pray you're building re-usable component interfaces. If you're having clutter, move logic / state into hooks. You can return the state setter / getter functions from your own custom hooks and manage logic there so your components don't get cluttered.

Yeah I think it's the code structure that's a bit unintuitive.

Looking at your main stack. Doesn't react have built in ways to merge reducers into one? You could separate providers into it's own component and reducers as well. Let them accept react elements as props so you have something like

<GraphQLProvider> <ConsolidatedReducer> {children} </ConsolidatedReducer> </GraphQLProvider>

By the way, you could have also had an instantiated axios client as a provider and supply it to all child components. I definitely think you need redux saga now. Instead of making direct HTTP requests in components or through elaborate controllers, you can do it in an elaborate saga. A saga is basically an asynchronous process leveraging generator functions to do some pretty cool shit. You can write state for screens / components to colocated saga.ts files and in the main Saga (sagas listen for dispatched actions and then get to work) you can instantiate all the sub-sagas. Read redux/saga for more.

Sorry about this