The tagline for Redux Toolkit reads: “The official, opinionated, batteries-included toolset for efficient Redux development”. In this article, I would like to break down this statement, examine the claim to efficiency and give some examples to confirm its legitimacy.
The “official” part clearly shows that the creators of Redux introduced Toolkit after having recognised that in its original form, Redux requires too much boilerplate code. As this excess of code can become problematic and rather messy (particularly in larger, more complex applications), they decided to upgrade it to a more opinionated tool to alleviate the need. In doing so, they have provided clearer guidance, a set of practical instructions and “good defaults for store setup out of the box”.
There are a few ways to handle multiple packages used to create one project. The multirepo model assumes that the packages are located in different code repositories. Monorepo is a single repository that contains and handles different packages. Due to this fact, a monorepo can be mistaken for monolith architecture. However, let’s take a closer look at a project created as a monorepo and compare it with a monolith. We will notice that monorepo consists of multiple logically separated subprojects.
This article will focus on monorepo architecture as it seems like the most modern approach to build complex apps. It is successfully used by companies such as Google, Microsoft, Facebook, and popular projects such as Create React App, Babel, Storybook, Primer, Jest, Strapi and many more.
There are a lot of ways for services to communicate with each other. You could use REST API, GraphQL, SOAP, or even share databases. They all have their pros and cons (especially the last one), and they all share the same problem: coupling. No matter the direction of communication, there is always a little bit of knowledge embedded in your application. The knowledge that you deferentially don’t need (for most of the time). Is there any way to avoid such a horrible thing?