How To Build User Management App With Master/Detail

User Management application contains more fields than the previous task management application, in this example I will explain how to create and update these fields in the Drawer we call Master-Details.

[Demo]

If we remember our previous Task Management application, it is a screen in the image below where we can only update the title, Task name and then Status.

However, since the data entry area is small in the above example, I would like to realize another application example that will make it a little more complex. Here we will perform the detail operations inside this detail Drawer screen. You can access this application (User Management Application) from this link.

Thus, we will open extra space for such form operations.

I prefer this method to the Table Cell Editing method,

Reason;

• Movement in the Table Row is restricted.
• The object in the Row may have data that is not shown in the Table, it is easier to show them in a scrolling area in the Details area.
• When there is no general Accept/Reject during Table Cell Editing, it will be necessary to send repeated requests over the network in each Cell update.

Instead of this;

We will be trying the method that opens in Drawer; In this method the form screen will be displayed for example

• When we say Create New User ,
• When we say Update User, You can do all our operations on a Drawer that opens from the right as below.

In this section, let's take a look at how the application works.

• User Creation
• User Update
• User Deletion
• Selectively Delete Multiple Users

While developing these parts, we have specifically followed the architecture here, where each component (page-components) can be used directly on the page without depending on other components.

• React Query
• Zustand
• React Router

In this way, each component was able to access the information it wanted to get and the information it wanted to change through the Container. In this way, we have an infrastructure that can grow in a very flexible and scalable way.

When using this architecture, I use the same blog post that I wrote in 2020 in this architecture description. I just changed it to → Hook structures instead of Class Component, but the logic is the same.

Components only compose to host others in their own structures. Components make their data needs or changes through Container Wrapper.

During this structure, the component inside is a Dummy component, maybe it knows Style, maybe Formatter, but it does not know Domain Data, it does not manage Domain Data, Containers manage it. We call this pattern Container/Presentation Pattern.

The important thing here is that we aim to keep the components inside as far away from the data as possible and write them as components that can be used over and over again. The component inside will only receive Props and will communicate via Container as follows.

Let me give a code example for a better understanding of the subject.