Enzyme VS Next.js

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.

Repository: Next.js

Next.js: npx create-next-app@latest

Remix is a very cool React-based framework that makes the final jump back from the browser to the server. After starting with SPAs that fully ran in the browser, Next.js got the idea of rendering React components in the server, reducing the initial load time and improving crawlability. Remix takes this a step further: while Next.js cannot render dynamic content on the server, Remix can. As a user, this means even faster loadings times for any kind of dynamic content, and as a developer, you don't need to think about server-side vs client-side components. You just write React code, and it works.

Here is the tricky situation and that's why CRA is in a semi-dead state, it has not been deprecated but isn't receiving any updates not even security updates, along with that the new React.dev documentation doesn't mention CRA but suggests using React meta-frameworks like Next and Remix for new projects. You can read more about React's reasoning for it in this github issue discussion.

Probably the most known example https://github.com/vercel/next.js/discussions/19065

It was not an issue if you host in Vercel, as they provide the image optimization as a premium feature.

Implementing the requested feature would make the framework much better when self-hosted elsewhere. But there is neglection to resolve the issue. This is just one case.

This Reactjs version also includes React Server Components, so you can easily render components on the server. If you’re familiar with Next.js, whose components are server components by default, this is the same idea. Server components have advantages such as faster page load time, better SEO optimization, and overall better performance.

Next.js - for creating the application’s user interface and backend.

On fresh install (ts version), every page inside /src/app will throw module not found errors on imports. This is probably because in tsconfig.json, moduleResoultion is set to bundler. More here - https://github.com/vercel/next.js/discussions/41189

Next.js is a powerful React framework, that is widely used for building server-side rendered (SSR) or static web applications. Dockerizing a Next.js application can streamline the deployment process and ensure consistency between development, testing, and production environments