@biglogic/rgs 3.7.6 → 3.7.8

package/docs/chapters/06-case-studies.md

@@ -1,69 +1,69 @@
-# 🛒 Chapter 6: Case Studies - Real Strategies
-
-In this chapter, we put theory aside and see how RGS solves the problems that keep you up at night (or at least frustrated in the office).
-
----
-
-## 🍎 Case 1: High-Performance E-commerce
-
-**The Problem**: A shopping cart with 50 items, complex sidebar filters, and a product list that must update without "jumping" the whole page.
-
-**The RGS Strategy**:
-
-1. **Atomic Filters**: Don't save the entire filters object. Use separate keys (`category`, `priceRange`, `search`). This way, if the user only changes the price, the search bar doesn't re-render.
-2. **Persistent Cart**: Use `gstate` with a `cart` namespace.
-3. **Computed State for Totals**:
-
-   ```javascript
-   cartStore.compute('totalAmount', ['items'], (s) =>
-     s.items.reduce((acc, curr) => acc + curr.price, 0)
-   );
-   ```
-
-**Why do this?** Because the component displaying the total price updates *only* when the `items` array changes, not when the user's name or shipping address changes. **Zero waste.**
-
----
-
-## 📊 Case 2: Real-time Dashboard (Sockets/Events)
-
-**The Problem**: You receive thousands of updates via WebSocket (e.g., crypto prices or server notifications), and React can't keep up.
-
-**The RGS Strategy**:
-
-1. **Atomic Transactions**: In RGS, you can group updates.
-
-   ```javascript
-   socket.on('bulk_update', (data) => {
-     store.transaction(() => {
-       data.forEach(item => store.set(`price_${item.id}`, item.price));
-     });
-   });
-   ```
-
-**Why do this?** Instead of triggering 100 React updates, the `transaction` triggers **only one** at the end. Your dashboard's performance will go from "tractor" to "Ferrari".
-
----
-
-## 🏦 Case 3: Multi-Step Forms (User Onboarding)
-
-**The Problem**: A signup form with 5 steps. If the user hits "Back" or refreshes the page, they lose everything.
-
-**The RGS Strategy**:
-
-1. Use a dedicated `gstate` called `onboarding`.
-2. Enable `persist: true`.
-3. At each step, just call `set('step1', values)`.
-**Why do this?** Because you don't have to manage manual saving logic. When the user returns, the fields are already populated. At the very end (Step 5), call `store.destroy()` to clean up. Clean and elegant.
-
----
-
-## 🛡️ Message for Advanced Architects
-
-*"But I could do all this with a custom cache and an event bus..."*
-Sure you could. You could also walk to work instead of driving. But RGS is the car: it's tested, it handles edge cases (closed tabs, full storage, corrupted types), and it lets you focus on **business logic**, not infrastructure.
-
-Stop reinventing the wheel. Use RGS.
-
----
-
-**Next step:** [FAQ: For the Skeptics and the Curious](07-faq.md)
+# 🛒 Chapter 6: Case Studies - Real Strategies
+
+In this chapter, we put theory aside and see how RGS solves the problems that keep you up at night (or at least frustrated in the office).
+
+---
+
+## 🍎 Case 1: High-Performance E-commerce
+
+**The Problem**: A shopping cart with 50 items, complex sidebar filters, and a product list that must update without "jumping" the whole page.
+
+**The RGS Strategy**:
+
+1. **Atomic Filters**: Don't save the entire filters object. Use separate keys (`category`, `priceRange`, `search`). This way, if the user only changes the price, the search bar doesn't re-render.
+2. **Persistent Cart**: Use `gstate` with a `cart` namespace.
+3. **Computed State for Totals**:
+
+   ```javascript
+   cartStore.compute('totalAmount', ['items'], (s) =>
+     s.items.reduce((acc, curr) => acc + curr.price, 0)
+   );
+   ```
+
+**Why do this?** Because the component displaying the total price updates *only* when the `items` array changes, not when the user's name or shipping address changes. **Zero waste.**
+
+---
+
+## 📊 Case 2: Real-time Dashboard (Sockets/Events)
+
+**The Problem**: You receive thousands of updates via WebSocket (e.g., crypto prices or server notifications), and React can't keep up.
+
+**The RGS Strategy**:
+
+1. **Atomic Transactions**: In RGS, you can group updates.
+
+   ```javascript
+   socket.on('bulk_update', (data) => {
+     store.transaction(() => {
+       data.forEach(item => store.set(`price_${item.id}`, item.price));
+     });
+   });
+   ```
+
+**Why do this?** Instead of triggering 100 React updates, the `transaction` triggers **only one** at the end. Your dashboard's performance will go from "tractor" to "Ferrari".
+
+---
+
+## 🏦 Case 3: Multi-Step Forms (User Onboarding)
+
+**The Problem**: A signup form with 5 steps. If the user hits "Back" or refreshes the page, they lose everything.
+
+**The RGS Strategy**:
+
+1. Use a dedicated `gstate` called `onboarding`.
+2. Enable `persist: true`.
+3. At each step, just call `set('step1', values)`.
+**Why do this?** Because you don't have to manage manual saving logic. When the user returns, the fields are already populated. At the very end (Step 5), call `store.destroy()` to clean up. Clean and elegant.
+
+---
+
+## 🛡️ Message for Advanced Architects
+
+*"But I could do all this with a custom cache and an event bus..."*
+Sure you could. You could also walk to work instead of driving. But RGS is the car: it's tested, it handles edge cases (closed tabs, full storage, corrupted types), and it lets you focus on **business logic**, not infrastructure.
+
+Stop reinventing the wheel. Use RGS.
+
+---
+
+**Next step:** [FAQ: For the Skeptics and the Curious](07-faq.md)