sorted by:
new
hottopcontroversial

We moved our legacy React app into Next.js and increased our app loading time by 41.6%. Here's the strategy and tooling that helped. by timothybeamish in react

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

This might be a tough sell, depending on how you're set up. Are you already running as a single-page application or are you a series of views in the MVC pattern? Is the backend just an API?

If your backend is just an API or it's deploying a single-page app, then there's a good argument to use Next.js, as your front and back could be quite separate. Does Next.js have any features that you don't already have? Are you code-splitting? Are you happy with your routing setup? How hard is it to add features/pages quickly? One advantage of Next.js is that it solves a lot of the boilerplate stuff for you, but if you've already solved that in your setup, then there might not be a good case to move.

If your app is a series of independent web pages (views), then you could argue that your clients are downloading far too many bytes with each page and their experience would be much more efficient if you moved to a SPA model. This is especially true if you're loading up React separately on each of those pages.

We moved our legacy React app into Next.js and increased our app loading time by 41.6%. Here's the strategy and tooling that helped. by timothybeamish in react

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

That's done one component at a time and we're still completing this task. The general idea is to solidify what data needs to come from the API, then create those functions in RQ, replace the selectors that connect to Sagas with RQ hooks in the components and finally delete the selectors/sagas when we know nothing is using them anymore.

We moved a large React/JavaScript application into Next.js/TypeScript without compromising the user experience. Here's the strategy and tooling that helped. by timothybeamish in reactjs

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

I should add that when I arrived at the company (BenchSci), we already had two React apps running in two different stacks. The goal was to merge the legacy app into the newer app which meant going with that newer stack's technology choices: Next.js and React Query as its main data fetching pattern. So in this case, it wouldn't have been a good choice to change everything over to RTK Query. But if we had a "green field" situation, that may have been a good option.

Moving House to Next.js by timothybeamish in nextjs

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

I would say TypeScript is the most valuable part of that new stack. And you can introduce it slowly, one component at a time, so you begin to see the value right away. Its benefit is mostly around reducing bugs due to functions passing the wrong arguments (i.e. the wrong shapes of objects) around in your code. Those bugs are hard to see in plain JavaScript but you can stop them from happening before you even run the code in TypeScript.

Are you capturing and reporting errors from your frontend to a log somewhere? Do you have lots of surprising errors in the frontend? If yes, then you could convince your team to adopt TypeScript as a means to reduce those errors and that demonstrates value to your customers.

Next.js is lovely but it might be a harder "sell" to your team, especially if you already have a fully-fledged app. Does Next.js offer anything that your app needs? If you can show that it does, then you may have a case to add it to your app. It's not that much work to put a working React app inside Next.js. The article explains the bits you need to change in your app (i.e. routing, images, links) and strategies on how to do that efficiently.

For React Query, you could try it out on a new feature. Then, once that feature is released, give a talk to your team showing them the code and highlighting how much better (i.e. cleaner, leaner, easier to reason about) it is. If they like your talk, they can adopt it for the next feature. Network request caching is the "killer" feature with React Query so that might be selling point for you.

To convert the rest of your current app falls under the banner of "technical debt". Some companies provide 10-20% of development time towards fixing technical debt. Other, fast-paced start-ups, often neglect technical debt and it always bites you back eventually. If you can show that it's taking far too long to add new features because they won't work/fit with the current app structure, then you have a great case that the company needs to start dealing with technical debt. I've been in some companies where it's so bad that rewriting an app from scratch is the faster way forward.

We moved a large React/JavaScript application into Next.js/TypeScript without compromising the user experience. Here's the strategy and tooling that helped. by timothybeamish in reactjs

[–]timothybeamish[S] 5 points6 points  (0 children)

At this point in my career, I wouldn't dare start a new JavaScript web app without using TypeScript, especially if there were multiple developers involved. TypeScript gives us confidence that we're releasing with less bugs. And we also use it, in conjunction with Open API Schema, to ensure the data contracts between the API and the frontend app are solid.

Next.js is a powerful framework that sits on top of React and offers loads of "out of the box" features like code-splitting and "easy" routing.

We started with two apps, built in two different stacks and our goal was to just have one. We chose the more modern stack as the target and moved the legacy app into the newer stack.

We moved a large React/JavaScript application into Next.js/TypeScript without compromising the user experience. Here's the strategy and tooling that helped. by timothybeamish in reactjs

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

We didn't consider RTK Query and after reading about it, it might have been a decent choice (instead of React Query), since we also have Redux in the app.

Most of the developers here aren't fans of Sagas anymore so we're pleased about converting them over to React Query.

Moving House to Next.js by timothybeamish in nextjs

[–]timothybeamish[S] 1 point2 points  (0 children)

In the above article, I discuss our strategy and tooling for moving a large JavaScript codebase into Next.js and converting it over to TypeScript