You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The User Management Demo showcases the polymorphism and dynamic behavior of the Effector Models API. It manages a list of heterogeneous user types (Guests and Members) with varying capabilities and visual representations.
6
+
7
+
## 2. User Entities & Roles
8
+
9
+
### 2.1. Guest
10
+
11
+
-**Definition**: A temporary user with minimal attributes.
12
+
-**Visuals**:
13
+
-**Avatar**: 👋 (Waving hand). Size: 1.5rem.
14
+
-**Style**: "Dull" appearance. **Name is grey** (`text-gray-600`). Low contrast to indicate limited status.
15
+
-**Indicators**: No special icons.
16
+
-**Capabilities**:
17
+
-**Kick**: Can be removed from the system.
18
+
-**Promote**: **Button Removed**. Guests cannot be promoted.
19
+
20
+
### 2.2. Member (User)
21
+
22
+
-**Definition**: A registered user with a persistent profile.
23
+
-**Visuals**:
24
+
-**Avatar**: 🙂 (Friendly smile). Size: 1.5rem.
25
+
-**Style**: "Cool" and standard. Indigo/blue accents, clear text.
26
+
-**Indicators**: No special icons.
27
+
-**Capabilities**:
28
+
-**Promote**: Can be upgraded to the "Admin" role.
29
+
-**Kick**: Can be removed from the system.
30
+
31
+
### 2.3. Member (Admin)
32
+
33
+
-**Definition**: A privileged user with administrative rights.
34
+
-**Visuals**:
35
+
-**Avatar**: 😎 (Cool with sunglasses). Size: 1.5rem.
36
+
-**Style**: Prominent and bold. Enhanced highlighting (e.g., indigo/purple border or background).
37
+
-**Capabilities**:
38
+
-**Demote**: Can be downgraded to the "User" role.
39
+
-**Immunity**: **Cannot be kicked**. The system must prevent removal of administrators at both the UI and Logic levels.
40
+
41
+
## 3. Functional Requirements
42
+
43
+
### 3.1. User List Management
44
+
45
+
-**Polymorphic Storage**: The system must support a single list (`usersList`) containing both `guest` and `member` model instances.
46
+
-**Addition**: Users can be added as "Guest", "Member (User)", or "Member (Admin)".
47
+
48
+
### 3.2. Role Transitions (The "Promote" Feature)
49
+
50
+
-**Action**: A contextual button that changes based on the current role.
51
+
-**Member (User) -> Member (Admin)**:
52
+
- Triggered by the "Promote" (↑) button.
53
+
- Updates the user's role and refreshes visuals (adds star icon).
54
+
-**Member (Admin) -> Member (User)**:
55
+
- Triggered by the "Demote" (↓) button.
56
+
- Updates the user's role and refreshes visuals (removes star icon).
57
+
-**Guests**: This feature is completely unavailable for Guest users.
58
+
59
+
### 3.3. Removal (The "Kick" Feature)
60
+
61
+
-**Requirement**: The system uses a "Kick" metaphor for removal. The generic "Delete" (🗑️) button is strictly forbidden.
62
+
-**Availability**:
63
+
-**Guests**: "Kick" (×) button is visible and functional.
64
+
-**Member (User)**: "Kick" (×) button is visible and functional.
65
+
-**Member (Admin)**: "Kick" (×) button is **hidden**.
66
+
-**Security**: The logic layer must verify the user's role before processing a removal request. If a "Kick" event is received for an Admin, it must be ignored.
67
+
68
+
## 4. UI/UX Specifications
69
+
70
+
### 4.1. User Item Component
71
+
72
+
-**Selection**: Clicking a user item selects it, displaying detailed information in the side panel.
73
+
-**Hover State**: Action buttons (Promote/Demote/Kick) should appear or gain opacity on hover.
74
+
-**Layout**:
75
+
- Left: Name and ID.
76
+
- Right: Contextual action buttons.
77
+
78
+
### 4.2. Detailed View
79
+
80
+
- Displays the selected user's ID, Name, and Role.
81
+
- Role must update reactively when a user is promoted or demoted.
82
+
83
+
## 5. Technical Architecture (Effector Models)
84
+
85
+
### 5.1. Model Structure
86
+
87
+
-**`guestModel`**: Includes `chatUserFacet`.
88
+
-**`memberModel`**: Includes `chatUserFacet` and `memberFacet`.
89
+
-**`userUnion`**: A union of the two models above.
90
+
91
+
### 5.2. Logic Implementation
92
+
93
+
-**`match()`**: Used in the controller logic to route the `toggleRole` action only to model instances that support the `membership` facet.
94
+
-**`select()`**: Used in the view layer to reactively extract `$role` and `$nickname` from the polymorphic model instances.
95
+
-**Guard Samples**: Use Effector `sample` with `filter` to implement the Admin immunity logic.
0 commit comments