3 ms·
I just did a migration for a pretty large CRA app to Next.js, and it wasn't particularly simple. A lot of stuff changes - for instance `react-router` is common
by presentation 5y ago
I just did a migration for a pretty large CRA app to Next.js, and it wasn't particularly simple. A lot of stuff changes - for instance `react-router` is common in CRA but NextJS has its own routing system and link components, `loadable-components` is what we used in CRA for code-splitting but instead Next has `next/dynamic`, managing the `head` also changes... these differences pile up.
I ended up making contexts that contained generic cross-platform implementations of stuff like links and dynamic components, that shared code could consume in order to function on both CRA and NextJS simultaneously - this made it possible to move things incrementally.
- terandle 5y agoWhat were the benefits you saw after moving to next.js? Personally I'm still using CRA unless I need SSR as I prefer react-router to file based routing.
- presentation 5y agoOur site went from largest content display of several seconds to <1s. Also we don't need to use Prerender anymore to give real HTML to dumb crawlers that don't run JS.
- rattray 5y agoAny chance you could share some of those? Have looked at doing the same thing for a few apps and the risk/difficulty of trying to do it in One Big Pull Request was too much each time...
- presentation 5y agoThere’s some stuff that is specific to our site (we have custom link components for instance) but yeah I can post it somewhere. I’ll put together a post when I have some spare time.
- sergiotapia 5y agoI'm migrating away from clientside entirely. Back to server side rendering; it's been cool but I'm just tired of it. You have to do so much crap to get stuff running nicely and it's all very brittle. code splitting, routers, changes to <head>, links, permissions, etc. I'm hitting the reset button and going all in with server side render templates again. Going to PETAL stack.