You. Hello. Welcome to Conf 42. Today I will be talking about modular approaches of structuring react and redux apps and a little bit about me. My name is Sergi, I'm from Ukraine. I have been working as a web developer for about 1010 years more and I work with different technologies and platforms, but last time I worked mostly with front end and with react. I'm really a fan of JavaScript so I participate in different events and I write articles about it and also I conduct JavaScript courses sometimes and also I like table tennis, fishing and traveling. First of all, let me introduce a little bit what we will be talking about today. And I will start from talking a little bit why good structure of redux application is important and about state management problem at all. What is wrong with common approaches in redux applications? We will check what is dax and reducks, what is redux toolkit, and a little bit about testing of Daxis. What is problem with state management? State management in modern front end applications is quite a common problem for different frameworks and libraries, but especially it's a problem in react ecosystem. I think that one of the reasons why we have the state management problem in react, it's because we have different types of state. First of all, we have components. Local state is the simplest state. And today, using hooks, we can have local state in functional components. And also of course we can have local state in components, class based components. Next type is components shared state. And sometimes we need to have a data, some data that we need to display in different components. And one of the easiest approaches that people usually use is to lift up the data into a common parent and then pass this data via props. By the way, today I think you heard about recoil library, and some people think today that for such types of state, recoil can be a good one. Maybe. By the way, I had some articles and presentations about recoil, just check it. But in Internet. Yeah, thank you. And applications global state, it's a main type, I think of the state in our react applications and usually it can be an object and quite a big one that contains all the data from all our applications application. And we use this data in different components. And I think that this global state usually can be splitted. It contains as well two main parts. It's a UI state and cache UI state. It's a data that we use to configure our application and it's something that we use a configuration for the look and feel like theme, and also it's a data that we display. And what about the cache. Almost all our modern applications, they do API calls. And when we retrieve the data, usually we also store it and we need to call it cache because it's actually a cache. And I think that most of the developers that work with Redux, we all do such things like API calls and store the data into our global state with all the rest of the data. And right now a lot of developers started to think that maybe we need to separate this type of state, I mean cache into separate, maybe a separate object or separate state array, and maybe even different libraries can be used for different types of state. But today we will be talking about redux. And some people can say redux in 2021. Why? We have a lot of new stuff. Do we really need redux today? And I should say that we had several times we had situations when something appeared and some people said, okay, so now we don't need Redux anymore. The same thing was with context API. And I remember a lot of people said, okay, we don't need redux anymore. We have context API, but they will run, as we can see here, that context API, it was set last year that it cannot replace Redux. And we can see today, like here in the open base, you can check this Openbase website and they have this ten best react state management libraries article. And there you can see the list of most popular state management libraries in react. And just check the numbers for redux. So GitHub stars and weekly downloads, those numbers are amazing, but in the same time you can see that user rating is not the highest. And we all know that a lot of developers coplained a lot about Redux as well. But it's still very popular, why it's popular and why developers complain about it. I think that most problem about Redux, that people usually say it's about its boil plate. But let's talk about this a little bit later. At first, a small disclaimer, Redux, it's part of our application, it's a part of the architecture. Actually it's implementation of the flux architecture. But today we are talking about the structuring of the application because we decided that we use flux. If we use Redux, then we use flux architecture. But we mostly talk today about structuring the application. So what is the common problem of just standard react applications? Here we can see example of very popular, very common react redux application. And here we can see that all redux artifacts, they are spread it all over application into different folders. When we start our application, when application is small and we add redux it looks quite good. And when we add Redux and such folders, sometimes we can even think, now my application looks professional, but later when we need to maintain and support such project, it can become a nightmare to support it. Because just imagine when you need to add a new entity, you need to create the same files over and over again in different folders. If you need to modify files, you need to go to those files in different folders. If you need to remove entity, you need to go to different folders and remove different files. So this approach scales very bad. And yeah, it has a lot of problems. What we can do about this? First of all, I would like to recall that we have several approaches for structuring it's function first and feature first approaches. I think we all know about them here. I would like to add that sometimes we can mix those approaches and also one very important moment that we need to think about our application on the long run. So we need to imagine what happens if we switch from react to another library for example, or if maybe we will switch from react to react native. Yeah, then maybe we would be able to reuse some parts of our application and especially the state management. And that's why people started to think that maybe we need to separate state management from UI and ideally it can be added into a shared library. That's why Eric Rasmussen, he started to think about problems of Redux. He also didn't like that we need to add a lot of files in different folders and only because we need to import some actions or reducer. Ideally he thought that it would be better to isolate the model, the state management, our bundle, and ideally we even can move this bundle into a shared library. And here he created Daxis ducks. It's a one file that contains all redux artifacts. I mean it contains actions, reducers, action creators, selectors, saga and all of that. So everything that you have around one reducer that you need for one reducer you have in one files. Even tests can be added directly in this file sometimes. At first for some people it looked very scary, but for small applications, when we don't have a lot of code for those artifacts, that idea was awesome. When I first look at this, I liked this and I tried in some applications and I also proposed this approach to my colleagues, but they afraid to try this at first. Daxis has some rules and when you follow those rules, then you will be able to import actions and reducks. By the way, why docs? Eric explained it that he thought that Java has jars and beans. Ruby has gems. So he just suggested to call those reducks bundles as Daxis or DAX as last syllable of redux. How we can use docsis. So when we have everything in one file and we export only reducers and only actions. So when we need reducers we still can just import them directly from one dux. The same for actions. When we need actions we also can import them from the same duck. And if you need anything else it's quite flexible. So you also can export another artifacts that you need actions from the ducks and then you can import them. Here. I added a few links to different implementation of Daxis today. Maybe they can look a little bit outdated, but today I'm talking about Daxis and I will be talking about reducks now just to go through the history of the redux evolution. And Dax was the first attempt, as for me, to change the rules of the game and after that redux appeared. The difference between DaX and Redux is that Dax's modular approach is nice, but it doesn't work. When we have a lot of code in the same file then it can be a problem to support such file. So some people, they proposed to split the code from the docs into several files. So here we can see example of the redux doc. By the way, the name also just created to sound like Redux. And here we can see that in one ducks folder. Ducks is one of the entities of our application like user. We can have different files in this folder like actions, operations, reducks, selectors, test types, utils and we export anything that we need from this folder via index file. Redux also has some rules that you need to follow. So like DAC contains concepts or I call them artifacts that are related only to one entity like product card and all of that. It's one doc years. So we should have index files that exports everything and we split reducers, selectors, actions and all of that. We keep them in separate files. And also this folder can contain tests. Of course, here we can see example of types. They can be the same or similar on Daxis in reducks, but of course in Daxis they are edited in the same file and redux in the separate file. So we can have actions, operations, reducers, reducers. By the way, it's the main part of the redux. That's why all this approach, Dax and Redux, they were built around reducers, as I said, reducers bundles. So daxes are actually reducer bundles. Yeah. Also we can have selectors. By the way, I like to use reselect. I hope you do. With Redux. And we of course have index file where we import and export all the stuff that we need in other parts of our application. And about DAX tests for Redux and DAX, we can easily add tests directly in the DAX folder and then all tests that are related to our Redux artifacts, they are bundled together with the code that we test, and it's very scalable. So when we need to add a new entity, again, we add all the code and we add the tests in the same folder. And when we need to remove one entity, we just remove ducks and at all, we remove ducks with all artifacts and with tests as well. And finally, we have a Redux toolkit. Redux toolkit. I think it's an amazing thing. And as for me, Redux Toolkit is a logical continuation of this saga, I mean story with Daxis. I think that Redux toolkit slices that we have, they implement exactly the idea to bundle all the stuff that we need for one reducer in one place. Redux toolkit, it has very good documentation, a lot of different articles and all of that. So you can investigate. And I think you already use it, most of you already use this. So I just want to remind a few things that Redux toolkit has. Redux toolkit has configure store. It's a helper or wrapper for create store. It help us to create store very easily with one or two, just a few lines of code. And by default it supports Redux thunk. But usually I use sagas, so you can easily configure a sagas as well. And also it supports redux details extension. It has createred function, it has create action, create slice and some additional utilities. Yeah, just a small summary. Redux, Redux and Redux toolkit. As for me, they use the same pattern or approaches for improving the structure of the redux application. React Redux feature basic separation of the redux code is more flexible and allows more opportunities for scaling when Cadaway is growing. But if we are talking about feature basic separation of the redux code, not when we are talking about all react application. So very important thing is to move all state management aside. For example, sometimes I just create redux folder and then I place all ducks here. There. Yeah. So redux toolkit provides useful tools and best practices. And really it is. So I think many of you heard that for angular, when people say about angular, even about Vue js, that when newcomers start to work with those frameworks, they can easily do the correct structure because they don't have a lot of options. But with react and Redux we had very flexible approaches so we could implement anything so newcomers could create not very optimal solutions and structures. But Redux toolkit is exactly quite opinionated tool for structuring redux applications. And by the way how do you structure your Redux app? Please share by the way here I added a bunch of links to their articles or comments that I shared in my talk and also I added a link to my repository and to the repository that I created especially for Con 42 and there I added quite simple basic redux application and also I created different branches where I refactorate the basic application with different approaches. At first it's improved redux approaches, then with Daxis, with reducks and with Redux toolkit. So if you would like you can check that repository. I have just quite basic stuff there but I plan to improve this repository for better user experience so you can investigate and compare and thank you.