I have always started my new web projects off with vanilla React, then added routing (react router), state management (zustand), etc., once I had the need for them. As the project would grow over time, more and more packages would need to be added. Eventually, you basically end up with your own custom framework. This is why the React team has started to recommend building new apps and websites with an existing React framework. Some currently supported production ready frameworks include Next.js, Remix and Gatsby. However, at the time of this writing, only Next.js supports all the latest React features, such as React Server Components (RSCs). Therefore, given the React teams recommendation to start new projects off with a framework, my own experience with building “custom” React frameworks and the ability to utilize cutting edge React features such as RSCs, I have started using Next.js for my new web apps. Here are a few challenges that I ran into, from the perspective of a React developer.

Recently, upon migrating Lali Solari’s personal website from vanilla React to Next.js (see this Contentful blog post for a great guide on getting started with Next.js App Router and Contentful), I decided to try out the Contentful GrapQL API. In the past, I have always used the Contentful Javascript SDK, which is a great tool for interacting with the Contentful REST API. However, I wanted to use the native web fetch API to take advantage of specific Next.js features, such as caching, so I decided to give the GraphQL API a try. Thanks to the GraphiQL browser tool and the ability to only get back the data that I need, I found the Contentful GraphQL API experience even better than working with the Contentful Javascript SDK.

I recently found myself needing to lift some parts of my application state into the URL. I usually default to use some state management solution in my web projects, and I am a huge fan of Zustand. However, there comes a time when using this type of state management alone may not provide all the desired functionality.

Why Lift State

Normally, when using something like Redux, the global store lives in memory within the JavaScript runtime of your application. This generally would work great, but what if a user wanted to share part of their application state with another user running the application on another computer? Or what if the same user simply wanted to share some application state between different tabs in the same browser? If all your state is stored in runtime memory, this isn’t possible.

Recently, I completed a large data migration on the PhotoVoice Japan website. The purpose of this migration was to clean up existing content models and utilize Contentful’s locales feature to allow for cleaner and more efficient multi-language support. Thanks to Contentful’s use of multiple Environments within a project Space, this migration was quite straightforward.

Cloning your Existing Environment

Fortunately, Contentful offers a very generous free “Intro” space license. Under the Intro license we are allowed three environments.