Gridsome VS Enzyme

Thanks for reading!

The web tech stack is actually one of my biggest regrets. It's a static site generator called Gridsome[0] that the maintainers abandoned about three months after I used it to launch the TinyPilot website.

At the time I made the TinyPilot site, I was very excited about Vue, so a Vue-based SSG seemed great. Since then, I've come to find SPAs and most frontend frameworks to be way too much complexity, so I've moved away from Vue, but the TinyPilot website is still stuck on Vue 2.x and bootstrap-vue (which is tied to Vue 2 and Bootstrap 4).

So, it keeps creaking along, but building the 100ish pages on the site takes about five minutes, whereas I think something like Hugo could probably do it in a few seconds. Plus, we get random runtime errors[1] that are pretty hard to debug.

[0] https://gridsome.org/

[1] https://github.com/nuxt/nuxt/issues/5800

Nuxt.js and Gridsome are tailor-made for Vue.js developers.

Gridsome — Jamstack SSG tool for Vue developers

Node is basically back-end Javascript. While powerful alone, almost exclusively you will use a back-end framework like Next.js or Gatsby when using React, and then maybe Nuxt or Gridsome in Vue.

Among other thoughts, I considered a possibility of migration to a newer tech stack (because I can). Don't get me wrong, I actually love Gridsome (which is underneath my website now). But it's quite obsolete, and it's actually a dead project now.

One downside of Gridsome is that development seems to have stopped if you look at their github. For that reason I've recently switched my Gridsome clients to Nuxt

I definitely think Nuxt is worth learning for more than just a static site. However, there is a Gatsby-like Vue framework that focuses on SSG: https://gridsome.org/

Gridsome

All the Static Site Generators have been in the market for many years. With time, they get new improvements and upgrades as well. While considering SSG frameworks, like Gatsby, Nuxt, Gridsome, Next, and many more have been on the developer’s list for a long time. But when we talk about blazing fast web performance as per core web vital, then we have to do a lot of work in the available frameworks, after connecting a lot of dots (in terms of web performance), but still, we cannot achieve the web performance as per our need if we consider a use case of a large website where 20+ components are in one page.

Probably Enzyme was the first to popularize component testing in React by doing shallow rendering and expecting some things to be there in the React component tree. Then React Testing library came and took component testing to a whole new level.

Enzyme is another popular testing utility for React. It allows you to manipulate and traverse React components' output, making it easier to write comprehensive tests.

ljharb is an extremely interesting person. There’s no doubting the positive impact he’s had on the OSS community and the work he’s done.

However, there are some things he does that are incomprehensible.

For example, Enzyme. Over three years ago this issue was opened for Enzyme on React 17: https://github.com/enzymejs/enzyme/issues/2429

Nothing moved for a while, and I think he said something along the lines of “if you want React 17 support, stop complaining and help”. So the community got involved. There are multiple PRs adding React 17 support. Many unofficial React 17 adapters. A lot of people have put a lot of work into this, ensuring compatibility, coverage etc. Yet to this day, none of them have been merged. Eg https://github.com/enzymejs/enzyme/pull/2564

Given the amount of time that has passed, and the work the community has put in, something is amiss. It feels like he’s now intentionally avoiding React 17+ support. But why? I don’t understand why someone would ask for help then ignore the help when it comes in. That isn’t much better than the swathe of rude/entitled comments he was getting on the issue before he locked it.

I ended up migrating to RTL, but this made many of my tests more complicated (especially compared to shallow rendering).

Enzyme Documentation

One way to do this is by writing tests for your React components. Tools like Jest and Enzyme make it easy to test your component's behavior, rendering output, and state changes. By writing tests for your components, you can ensure that they behave as expected and prevent issues before they reach production.

GitHub link: https://github.com/enzymejs/enzyme

So If you have experience with enzyme testing, where you might be checking the value of state once you click any button or you might be checking the prop value If something changes.

Enzyme offers two types of API for shallow rendering and full rendering. Both are preferred for different test scenarios and functionalities.

At Visa, I was writing unit tests for a Next.js project using components designed with Chakra UI. That's where React Testing Library came in handy. Unlike other solutions like Enzyme, I did not have to worry about the application snapshot but could instead focus on each UI element, its expected behaviour and the data it would render upon user interactions.

Superset uses Jest and React Testing Library (RTL) to write unit and integration tests. In the past we used Enzyme, but now that we're currently converting all of our class components to functional components, Enzyme cannot support our testing needs. Since RTL is better for testing functional components, we're converting all of our test files to RTL. This can be quite a learning curve - I've gone through a lot of the process so I'd like to share what I've learned so far.