Workpath

With ongoing refactors from Class to function components we also realized that Enzyme was not what we wanted. Instead of testing internals (like component state) we opted to go for a more user centric approach in our integration tests.

It also helps that react-testing-libraries is more straightforward and intuitive to understand for engineers than Enzyme. It's really just rendering into a DOM instead of making decisions about shallow and mount rendering.

So far we are very happy about that decision. Even Juniors love to work with it and regularly are excited to write and contribute to better integration tests.

In the past we used Redux to also store data coming from our internal APIs (via redux-saga). This data did not only contain the data but also meta information about the request status, i.e if a request is pending or failing.

Effectively we created a http cache layer on top of Redux.

Over time this grew into 10s of thousands of lines of boilerplate code which became very hard to maintain.

We started to investigate better solutions as we think Redux should be only used for "real" global application state and not persist data which might be used only in very specific parts of the application.

We investigated several solutions and came to the conclusion that react-query would be the best one.

We now have a nice abstraction to handle and cache server data. At the same time we were able to eliminate thousands of lines of code, making engineers very happy and improving developer experience.

This is an ongoing effort and will eventually result in an application where the global state is so small that we could even remove Redux.