SERVER, FRONT END ~ APRIL 13 2024
Although I have a lot of time for for SPA and React in particular, there comes a point when you realise that if you use it for public facing applications or 'Websites' in the traditional sense, there is a likelihood that no one will know about it. You may be lucky and have Google or other search engines index your dynamic content but there is wide speculation as to whether they do or not. It is safer to assume not and judging by some of my specific content, that certainly wasn't the case for me.
After so many years learning Software Development & delivering projects, I really wanted to start sharing my findings organically; I also want to use React as much as possible because it is a positive experience that offers a lot of creativity and flexibility for Developers & for the products they ultimately deliver to end users. React continue to improve Server Side capabilities like SSR but at the moment these are mainly building blocks that would take a considerable amount of time to pull together into something meaningful. A good example of that would be DOM APIs.
With the clear endorsement of Next.js by React, it is the obvious next step & one I've been determined to take to reach this goal.
Next.js is a 'React Framework for the Web'. What that means is subjective but the main feature Next adds to the already powerful React ecosystem, are the built in Server Side Rendering capabilities.
The first thing that struck me was the ease of entry to a Next.js project. You could quite easily build a full, feature rich Application, with just one package and a handful of commands. Most of us obviously wouldn't, but if you've been on the Journey through everything it takes to get a fully featured React project off the ground, you'll appreciate how much Next.js packs into one package and have it all work together *flawlessy. *nothing is ever 'flawless' but you know what I mean.
The standout concept for success with Next.js, at least in my use case, was Hydration. It is a bit of a Dark Art. To begin with, you feel almost as if you are hacking the Application into being but when the concepts sink in, you start to think a bit differently; Next.js is all about what gets rendered on the server and what does not. Your heart will sink a few times when it comes to peeking at the Source of your pages but when you think about the balance between Client & Server Components, delivering data in the right way to them, clarity will prevail. That's Development.
You can't go too far wrong as long as you adhere to the usual rules of functional programming and React component orchestration; reading about the concept of Fast Refresh can really help embed how Next.js is built around this.
Next.js Apps have a strict folder structure. Some may dissapprove of this, saying it lacks flexibility and is too opinionated. I thought this to begin with but Next.js has a specific purpose and when you think about it, most professional React apps have settled on a convention for structure and naming anyway so this is easily appeased.
The latest version of Next.js (14 onwards) introduces a new app folder structure but for my use case, this still has a 'flaw'. It uses React Suspense by default and will inject a loading state between pages. I find this annoying and would rather either program efficiently and wait the small amount of time it should take to go from one page to another.
Another area I want to explore going forward is animation. The App I'm using as a test bed for Next.js happens to have Transition Animations (I'll write about this in another Blog one day) & breaking the flow of these with a LOADING page isn't a good thing for UX. Hopefully Next.js will realise this and include more options for loading, making it more of an opt in global state feature rather than a rendering one. Instead, I opted for the pages structure for now, which is not vastly different but does not use Suspense unless you want to.
Generally, both these options consist of a folder, named as you would want a page to be named, with the resources inside that folder to support that page. Naming of the Javascript (in my case Typescript, which Next.js also has default support for out of the box) impact the application for routing of subpages, so something like [slug].tsx would support a parent index.tsx page, allowing you to automatically pass url paramters into it, capture them in an object like this { params: { slug: "hello-world" }} and respond accordingly.
The great news for React developers who maybe tentative about taking the plunge, is that there was a fair amount of reuse of components. There are two main areas where you have to think differently though and I did have to rethink how I got Data into the App and my approach to navigation a fair bit. Also, internal React based renderable state will never appear on the server so don't bother!
The main thing that kept me motivated during the migration however, was looking at a full page of content whenever I hit the 'View Source' button!
With all that learning & development, there's only one thing left to say - hello Google, it's been a while.