Good article! I pretty much understand the concept but still have one question; in what condition should we start separating the code into module? Thanks
Imagine an application to manage public events, something like an enterprise version of meetup. Users are in this case those who create and manage the events. They can create programs, determine if the events are closed, configure website, etc. However, there is no Active Directory or anything available. So users and their authentication details are managed by the same backend as all other aspects of the application.
In the front-end, this is very good example of a contained module. We have to be able to create, edit, delete and read basic information of users. Handling of sending authentication emails etc. is being done by the backend. But why is this a good example of a module?
Lets assume we are building a front-end for a back-end by using standard fetch-requests, or use something like the library axios. We are also using a single application store is used for state management (e.g. redux). And for good times sake, it is a single-page application (SPA).
On the highest level, we are going to point our router towards the user module, the moment someone browses to /users/?…. At this point, our module can handle the nested routing for us, the application router does not have to do anything. In the module, we have an overview page on the index (e.g. showing a table of users for address /user), but we also have pages around create, edit, and maybe also for your own profile (as this might differ from a standard edit page).
To make these pages work, the module also handles all the CRUD requests towards the back-end, assuming they follow the same structure (e.g. they point towards the same endpoint group). This configuration of these fetch-requests, is also part of the module. But the responses of these requests are handled in the application state when applying optimistic UI. The module handles where and how this part of the application state looks.
Now assume we are in another part of the event-application. We want to change for instance the owner of an event. So we need a searcheable dropdown users. To fill this dropdown, we need to use atleast a get-request from the users end-point of the back-end. You could handle that in the page where it is located. But you can also create a UserDropdown component in the user module. This component can directly use the fetch-request already configured in the module. Furthermore, it can use the application state configured in the module. It can use existing users in the state to pre-populate the dropdown already. This way, all the logic and UI logic is handled inside the user module, and not scattered throughout your application and your code base.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Good article! I pretty much understand the concept but still have one question; in what condition should we start separating the code into module? Thanks
Imagine an application to manage public events, something like an enterprise version of meetup. Users are in this case those who create and manage the events. They can create programs, determine if the events are closed, configure website, etc. However, there is no Active Directory or anything available. So users and their authentication details are managed by the same backend as all other aspects of the application.
In the front-end, this is very good example of a contained module. We have to be able to create, edit, delete and read basic information of users. Handling of sending authentication emails etc. is being done by the backend. But why is this a good example of a module?
Lets assume we are building a front-end for a back-end by using standard fetch-requests, or use something like the library
axios. We are also using a single application store is used for state management (e.g.redux). And for good times sake, it is a single-page application (SPA).On the highest level, we are going to point our
routertowards the user module, the moment someone browses to/users/?…. At this point, our module can handle the nested routing for us, the application router does not have to do anything. In the module, we have an overview page on the index (e.g. showing a table of users for address/user), but we also have pages around create, edit, and maybe also for your own profile (as this might differ from a standard edit page).To make these pages work, the module also handles all the CRUD requests towards the back-end, assuming they follow the same structure (e.g. they point towards the same endpoint group). This configuration of these fetch-requests, is also part of the module. But the responses of these requests are handled in the application state when applying optimistic UI. The module handles where and how this part of the application state looks.
Now assume we are in another part of the event-application. We want to change for instance the owner of an event. So we need a searcheable dropdown users. To fill this dropdown, we need to use atleast a get-request from the users end-point of the back-end. You could handle that in the page where it is located. But you can also create a
UserDropdowncomponent in the user module. This component can directly use the fetch-request already configured in the module. Furthermore, it can use the application state configured in the module. It can use existing users in the state to pre-populate the dropdown already. This way, all the logic and UI logic is handled inside the user module, and not scattered throughout your application and your code base.