Yarn workspaces - splitting React app by routes

Hello developers!
I need your suggestions/help regarding the idea we had in our team.

We have a massive React/Redux/Sagas application which weights a lot, so we decided to split it based on routes. But suddenly one idea came to our mind: why not to move those "split routes" code into separate yarn packages (with reducers, sagas, etc)? We thought it would be easier to manage in the future.

Splitting code into multiple chunks that would be imported dynamically with Webpack also requires us to implement additional logic for importing reducers and sagas after the chunk is downloaded by the browser, but it's doable.

Could you please share your thoughts on this? Does it really make sense to go this way and use yarn workspaces?

Thanks!

Comments

[Antoine Lehurt]

That's an exciting subject. I think that's a good practice to split your application based on the routes as a first step for optimizing the first load. However, I have a few questions that come to my mind about your need for yarn workspaces.

• What would be the benefits of splitting your routes into different packages? "easier to manage" is a bit vague :)
• What would be the developer's workflow for running and developing the project? Compared to your current set up with one package.
• Do you see a need in the future to have different dependencies version? Or is the plan to share the same version across the packages?
• Do you also need to separate the build step? For instance, to decrease the build time for CI.

I only used yarn workspaces coupled with Lerna, so I'm also interested to hear more about how you plan to use it. Thanks :)

[Pavlo Tymchuk]

Hey Antoine!

Currently, we are looking for the best solution which will work well for us.
The biggest benefit to us is that multiple micro teams will be able to work on the same project without conflicting with each other. Going this way we can be also sure, that if someone broke something in one package then the other parts of the application will work. Also having something independent from the base project is easier to change/refactor.

During development we are using Webpack 4 with webpack-dev-server and babel-loader configuration. The thing here is that you need to compile your dependencies before running app, so for that we are using babel with watch flag. In the package.json file of the package we are saying that main entry file is "./lib/index.js" like you do normally for libs. Thankfully to symlinks, we can "connect" packages in monorepo.

For now we don't care much about CI, but yes in future probably we will do something like you have mentioned :)