Lessons learned building a site with Gridsome

2020. Jan. 30. · 4 min read
Gridsome has nice documentation and it is easy to start using it. But I experienced some things which were not obvious to me or I feel good to emphasize. So I thought it worth to share them.

But you might not know what Gridsome is.

Let me introduce Gridsome!

Gridsome is one of the newest element of the List of Things I Like! (OK, it is not too useful information…)

Gridsome is a Vue.js based framework which

”makes it easy for developers to build modern websites, apps & PWAs that are fast by default”.

And it lets you build sites on the Jamstack. (Maybe you know Gatsby – it is similar to that. As the developers of Gridsome say “Gridsome is highly inspired by Gatsby.js”.)

Who is it for?

You know HTML, CSS, some JavaScript, basic command line usage and Git. You are good to go and in half an hour (or less) you already can have a new, modern presence on the web (for free) like this one!

(How? Find out on the Gridsome Blog Starter and on the Deploy to Netlify pages!)

What made me think (good, or not so much…)?

So what I want to write about in this post if it is so easy? Nothing horrible! Let me provide you with a simple but curated list of notes I took during the development of a demo site I built to learn about Gridsome.

Globally available components

We can register any of our custom components in main.js (like the Default.vue layout component is registered) to be available globally without the need to import it in the file where we want to use it! Means: we may refactor file structure, without breaking import paths! Downsides? I do not know. Eg. performance?

Reload the GraphQL Explorer page!

When you use markdown files as a content source you can add Front Matter fields to them which will be available automatically(!) in your GraphQL schema. But you have to stop and re-run gridsome develop and after that reload the GraphQL Explorer browser page to see the new elements in the GraphQL Docs/Schema. Easy to forget about…

The difference between “slug” and “slugify”

You can find both phrases in the documentation or you may know them from other platforms or tools and it can be confusing. Let’s clarify it a little!

Gridsome slugifies path parameters by default. Meaning: transforms strings to lowercase, dash-separated versions which are safe to use as part of a URL. (Eg. “I ♥ Gridsome” » “i-love-gridsome”.)

On the other side, you may have a Front Matter field called “slug” and this can be used as part of a path pattern. Like BlogPost: '/blog/:year/:month/:day/:slug'.

In addition in earlier versions of Gridsome a slug was auto-generated from post_title. But now title is used instead.

I had the idea to use an optional slug field. If I provide data in the slug Front Matter field that would be used as the source of the path, if not it falls back to the slugified title.

So I wrote in gridsome.config.js:

templates: {
  BlogPost: slug ? '/blog/:slug' : '/blog/:title',
}

But it does not work! Do not do this! It needs a more sophisticated solution. (I got a suggestion about it but still had no time to test.) :)

“Gridsome has a built-in <g-image> component that outputs an optimized progressive image. It also resizes and crops in real-time when developing.”

(And has other useful features too!)

We can resize and crop images just providing width and/or height attributes. The component generates an img element with an srcset attribute to load just the smallest needed size version of the image.

Unless we provide both width and height! Because then we will have only one image (with no srcset), sized exactly as we asked for.

Another thing:

“The gridsome-transformer-remark transformer plugin automatically converts normal Markdown images to g-image compatible markup.”

But in this case you can not define additional arguments like width or height!

Styling

It is possible to use SCSS for styling after a little bit of configuration. However, using global preprocessor files (eg. variables or mixins) needs additional configuration and it is surprisingly complex (compared to other things in Gridsome)!

On the other hand, you may not need Sass variables, because you have the option to use CSS Custom Properties instead which does not need the additional configuration. And as the documentation says:

“It’s recommended to keep the global styles at minimal and add styles in Vue components instead to get proper code-splitting and Critical CSS support.”

Dart Sass

Worth to mention that while the documentation recommends node-sass it is possible to use Dart Sass instead. You just npm i -D sass instead of node-sass. It is not possible however to use the new Sass modules as Webpack (and/or the style-resources-loader plugin) does not support it yet.

But again, you may not need it since with Gridsome you use a component-based framework already!

Add a CSS framework

If you want to do so, you can choose from the different options!

Conclusion

While Gridsome is very young (the current version is 0.7.12) you get a plethora of useful functions out of the box or after some not too hard configuration. And it provides an awesome developer experience!

Well, I’ve just built the first site with Gridsome but I’m sure that I will build a lot more! And as I’m a Drupal guy as well I have plans already to use the two together!