Gatsby the mister cool Dev Ux

12/20/2020
4 min read

Gatsby has been a game-changer over the past years in the React World. Now it’s even more fun and powerful.

It’s now easier for me to test something with Gatsby than the Create React App.

Disclaimer

It won’t be a complete guide even if I give some tips. It’s more about the way I feel about the framework and how I use it.

What is Gatsbyjs?

Gatsby is built on top of React. It’s a phenomenal framework that abstracts developers away from the complexity. It has tones of plugins and starters and tutorials you can use to speed up your dev.

They market the tool with the following catchy slogan :

create a complete website in the time it usually takes to build a prototype

It’s true. Every time I have a website to make, I definitely include Gatsby as a potential boost for the project.

DUx is great

When it’s for a personal project, such as my blog, I like to twist and push things to the limit. My blog is a great sample to deeply test a solution as I have many cases to handle, such as multilingual, all kinds of sorting, different types of content, forms, syntax highlighting, image formats, etc.

I like Gatsby because I can make those stupid proof of concepts and explore new techniques, but still, with a big help if I’m stuck anywhere.

At this time, I use the 2.29.1 version. Gatsby has excellent “new” features I’d like to share with you.

N.B.: I use quotes when I write “new” because I don’t know the exact version that introduces those great concepts.

New flags

Here are the flags you can use to make your Gatsby dev even more smooth:

  • PRESERVE_WEBPACK_CACHE to keep webpack’s cache when changing gatsby-node.js & gatsby-config.js files because you rarely need to delete it
  • FAST_DEV to improve dev server start time
  • DEV_SSR to detect SSR bugs and fix them without needing to build
  • QUERY_ON_DEMAND to only run queries when needed instead of running all queries upfront
  • LAZY_IMAGES to skip process images during development until there’s an explicit request for them from the browser
  • PRESERVE_FILE_DOWNLOAD_CACHE to keep the downloaded files cache when changing gatsby-node.js & gatsby-config.js files because, again, you rarely need to re-them
  • FAST_REFRESH to use React Fast Refresh instead of the legacy react-hot-loader for instantaneous feedback
  • PARALLEL_SOURCING to run all source plugins at the same time instead of serially

Source: config API Gatsby

Those flags are incredible. Indeed, many of them are experimental features, so it’s not like you use it without any problem in whatever situation, but it does speed up the dev.

To add a flag, open the gatsby-config.js file and add it on your config like that:

module.exports = {
  flags: {
    PRESERVE_WEBPACK_CACHE: true,
    FAST_DEV: true,
    DEV_SSR: true,
    QUERY_ON_DEMAND: true,
    LAZY_IMAGES: true,
    PRESERVE_FILE_DOWNLOAD_CACHE: true,
    FAST_REFRESH: true,
    PARALLEL_SOURCING: true,
  },
  siteMetadata: {
	/* your site metadata */
  },

Again, if you experience some issue, feel free to report it. There are dedicated links that display when you run gatsby develop in your terminal, so it’s easy to find the right place to report your issue.

You don’t have to use them all. As far as I know, QUERY_ON_DEMAND and PRESERVE_WEBPACK_CACHE are great to speed up dev.

DEV_SSR is an excellent addition, IMHO. It prevents nasty surprises at build time.

Less pain, more comfort

Before those flags and other excellent additions, there were cases where you could not get your modification without stopping and relaunching gatsby develop.

For example, every time you wanted to change something in config files such as gatsby-node.js to modify a GraphQL request or add a node url.

Now, you got both in the browser and the terminal an alert that lets you know that, so you only have to click “yes,” and Gatsby will handle that reload.

If you have any issue or prefer handling that in the terminal, you can still do that, but, as a developer, I appreciate this feature. This way, I can’t miss that point and spend minutes understanding why I’m not getting that stupid modification.

Conditional page builds

If you have Gatsby Cloud, then you should not use this feature. Otherwise, you may encounter conflicts.

It’s possible to mimic the fancy incremental feature that Gatsby cloud’s customers have. You can use:

GATSBY_EXPERIMENTAL_PAGE_BUILD_ON_DATA_CHANGES=true gatsby build --log-pages

As the documentation says, it’s, of course, only available for builds and not at development time. It compares page data between the previous and the next build.

Source: Gatsby documentation

Conclusion

Gatsby rocks!

While many features are still quite experimental, I love what this community does to improve developers' daily life.

I also like the opt-in approach. If you don’t want one of these flags or features, don’t use it or remove it.

See Also