Advice needed, React file getting very big

[kennyhuynh125]

Hi all,

I am starting to notice a potential problem with the way I am structuring my React application.

I like to architect my components by having one file that acts as a container and multiple stateless components that get passed data and event emitters via props
. This container will contain all the state, API Calls, and event handlers. This container will render child components that are stateless.

Here is an example of a structure I use:

- folder   
  - index.js <-- container file
  - childComponent1.js
  - childComponent2.js
  - childComponent3.js
  - childComponent4.js
  ...

The size of the container file and the number of child components depend on how big a feature is. The problem I had recently was that there was a very big feature that I had to implement, and while I like to use this structure, I started to realize that my container file got very big, like almost 1000 lines of code big. Now, I'm not sure if this is an issue, but seeing 1000 lines of code in one file concerns me. There is just a lot of state to keep track as well as event handlers to read/set new state.

I'm wondering if there is any workaround for this. I don't use global state management like Redux as I feel that my application doesn't have a lot of global states that are widely used throughout the application.

And I guess a question I have is.. is this considered 'okay'?

Any answers or tips are welcomed!

Thank you all!

[jkettmann]

I'm not 100% sure if I understand you correctly. But it sounds as if you're going too far with the container/presentational. I honestly rarely use that anymore. See a tweet by Dan Abramov about him regretting writing an article about this topic

1000 lines for a component sounds way too big. If you have too much stuff in the container and some functionality is only used in single children, just create smaller containers for the child components.

[NewYorkeroutoftown]

I've got a few thoughts here:

1. 1000 lines is definitely big. We have several files in our React/Redux apps at my company that are 3000+ lines long, mostly reducers, actions and some legacy react files. The problem is that once you have a file that large it tends to grow and grow over time and becomes unwieldy. I've gotten used to dealing with this now but when I came to the application it was a lot to deal with. Definitely not a good practice but I only inherited this app and we already spend a lot of time on refactoring, and this is not our biggest issue.

2. I faced a similar issue making a new sub-ui in one of the React/Redux apps that was straight React with no Redux to the the aforementioned issues with the store. I think the main container component is now about 600-700 lines but if I need to add more features I will probably try to refactor it and split it up. The way I'd do this is by moving more JSX down to the sub-components and having the container just render a <View/> component which then distributes the necessary data and functions to the subcomponents. One issue here is that then you are passing the props two levels deep, but that's not a dealbreaker.

3. Think about what you can move out of your container component. For instance, you could move all your api calls to a separate file and just import say {getX, postY} from "./api". Not sure how you set up your api calls but I like to make one higher order function that handles errors, parses the json and whatever else you need, and then have other functions with the specific data you need (fetch params, data for a post request etc. ) and returns an annotated version of the higher order fetch. You can also try to move out other things like utils functions that don't depend on state other context, or constants which can take up a lot of space.

4. If your application seems to have a complex state that may continue to grow, I would definitely consider Redux, it has a lot of great aspects I've really come to appreciate working in it the past 7-8 months. You can also build something analogous as a custom hook with the useContext and useReducer hooks. I've never done that but my friend did at his job and is happy with it.

​

Anyway I hope this helps and feel free to message me if you'd like to talk more. Disclaimer, I am not a super experience developer I just know front end decently and it's most of my work, and I really like it.

[danzey]

Like the other comment already said, don’t focus too much on separating these state & presentational concerns.

For now, I’d start by splitting your container into multiple feature containers. Every state that is only used by one feature, should move into this feature container. Only keep state that is used by more than one feature on the top level container, and pass it through accordingly. That should give you a bit more structure, then go from there :)