@biglogic/rgs 3.8.4 → 3.9.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +9 -13
- package/core/advanced.cjs +1 -0
- package/core/advanced.js +1 -0
- package/core/minimal.cjs +1 -0
- package/core/minimal.js +1 -19
- package/index.cjs +1 -0
- package/index.js +1 -3925
- package/package.json +43 -47
- package/types/rgs.d.ts +7 -0
- package/docs/README.md +0 -483
- package/docs/SUMMARY.md +0 -55
- package/docs/_config.yml +0 -1
- package/docs/chapters/case-studies.md +0 -69
- package/docs/chapters/faq.md +0 -53
- package/docs/chapters/getting-started.md +0 -68
- package/docs/chapters/local-first-sync.md +0 -146
- package/docs/chapters/migration-guide.md +0 -284
- package/docs/chapters/persistence-and-safety.md +0 -125
- package/docs/chapters/philosophy.md +0 -54
- package/docs/chapters/security-architecture.md +0 -50
- package/docs/chapters/the-magnetar-way.md +0 -69
|
@@ -1,69 +0,0 @@
|
|
|
1
|
-
# 🛒 Chapter 6: Case Studies - Real Strategies
|
|
2
|
-
|
|
3
|
-
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).
|
|
4
|
-
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
## 🍎 Case 1: High-Performance E-commerce
|
|
8
|
-
|
|
9
|
-
**The Problem**: A shopping cart with 50 items, complex sidebar filters, and a product list that must update without "jumping" the whole page.
|
|
10
|
-
|
|
11
|
-
**The RGS Strategy**:
|
|
12
|
-
|
|
13
|
-
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.
|
|
14
|
-
2. **Persistent Cart**: Use `gstate` with a `cart` namespace.
|
|
15
|
-
3. **Computed State for Totals**:
|
|
16
|
-
|
|
17
|
-
```javascript
|
|
18
|
-
cartStore.compute('totalAmount', ['items'], (s) =>
|
|
19
|
-
s.items.reduce((acc, curr) => acc + curr.price, 0)
|
|
20
|
-
);
|
|
21
|
-
```
|
|
22
|
-
|
|
23
|
-
**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.**
|
|
24
|
-
|
|
25
|
-
---
|
|
26
|
-
|
|
27
|
-
## 📊 Case 2: Real-time Dashboard (Sockets/Events)
|
|
28
|
-
|
|
29
|
-
**The Problem**: You receive thousands of updates via WebSocket (e.g., crypto prices or server notifications), and React can't keep up.
|
|
30
|
-
|
|
31
|
-
**The RGS Strategy**:
|
|
32
|
-
|
|
33
|
-
1. **Atomic Transactions**: In RGS, you can group updates.
|
|
34
|
-
|
|
35
|
-
```javascript
|
|
36
|
-
socket.on('bulk_update', (data) => {
|
|
37
|
-
store.transaction(() => {
|
|
38
|
-
data.forEach(item => store.set(`price_${item.id}`, item.price));
|
|
39
|
-
});
|
|
40
|
-
});
|
|
41
|
-
```
|
|
42
|
-
|
|
43
|
-
**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".
|
|
44
|
-
|
|
45
|
-
---
|
|
46
|
-
|
|
47
|
-
## 🏦 Case 3: Multi-Step Forms (User Onboarding)
|
|
48
|
-
|
|
49
|
-
**The Problem**: A signup form with 5 steps. If the user hits "Back" or refreshes the page, they lose everything.
|
|
50
|
-
|
|
51
|
-
**The RGS Strategy**:
|
|
52
|
-
|
|
53
|
-
1. Use a dedicated `gstate` called `onboarding`.
|
|
54
|
-
2. Enable `persist: true`.
|
|
55
|
-
3. At each step, just call `set('step1', values)`.
|
|
56
|
-
**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.
|
|
57
|
-
|
|
58
|
-
---
|
|
59
|
-
|
|
60
|
-
## 🛡️ Message for Advanced Architects
|
|
61
|
-
|
|
62
|
-
*"But I could do all this with a custom cache and an event bus..."*
|
|
63
|
-
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.
|
|
64
|
-
|
|
65
|
-
Stop reinventing the wheel. Use RGS.
|
|
66
|
-
|
|
67
|
-
---
|
|
68
|
-
|
|
69
|
-
**Next step:** [FAQ: For the Skeptics and the Curious](07-faq.md)
|
package/docs/chapters/faq.md
DELETED
|
@@ -1,53 +0,0 @@
|
|
|
1
|
-
# ❓ Chapter 7: FAQ - Architectural Insights
|
|
2
|
-
|
|
3
|
-
This section provides technical context for the design decisions behind RGS (Argis) - Reactive Global State.
|
|
4
|
-
|
|
5
|
-
## 1. "Why integrate Security and GDPR into the State layer?"
|
|
6
|
-
|
|
7
|
-
**The Rationale:** In enterprise environments, ensuring that every data access is authorized is critical. By integrating **RBAC** and **Auditing** directly into the store instance, we provide a "Secure-by-Default" architecture. This prevents common oversights where developers might forget to apply permission checks in custom middleware or component logic.
|
|
8
|
-
|
|
9
|
-
## 2. "How does RGS compare to the React Context API?"
|
|
10
|
-
|
|
11
|
-
**The Technical Difference:** Context is a dependency injection tool. When values change, React often triggers broad re-renders across the consumer tree. RGS uses a **Surgical Subscription** model. Only components observing a specific key are notified of changes, ensuring optimal performance even in data-heavy applications.
|
|
12
|
-
|
|
13
|
-
## 3. "Is there a performance overhead for Safety Features?"
|
|
14
|
-
|
|
15
|
-
**The Trade-off:** Capabilities like deep freezing (immutability) and sanitization do introduce a small computational cost (typically 1-2ms). We believe this is a worthwhile investment to prevent accidental state mutations and security vulnerabilities. For performance-critical scenarios (like high-frequency animations), these features can be selectively disabled.
|
|
16
|
-
|
|
17
|
-
## 4. "How is Type Safety handled with string keys?"
|
|
18
|
-
|
|
19
|
-
**The Approach:** String keys provide the flexibility needed for dynamic and runtime-generated state namespaces. For developers requiring strict type safety, RGS offers the `gstate` factory and `GStatePlugins` augmentation, allowing you to define a fully typed interface for your store and its plugins.
|
|
20
|
-
|
|
21
|
-
## 5. "What logic dictates the use of 'Ghost Stores'?"
|
|
22
|
-
|
|
23
|
-
**Operational Resilience:** Many applications experience race conditions during hydration or initialization. Instead of allowing the application to crash due to an uninitialized reference, RGS returns a protective Proxy. This Proxy logs a developer warning while providing a safe fallback, ensuring the user interface remains functional while the developer addresses the initialization sequence.
|
|
24
|
-
|
|
25
|
-
## 6. "Is it compatible with modern React patterns (SSR/Next.js)?"
|
|
26
|
-
|
|
27
|
-
**Yes.** RGS is built on top of `useSyncExternalStore` and is fully compatible with Concurrent Rendering and Server-Side Rendering (SSR). It works seamlessly with Next.js, Remix, and other modern frameworks without hydration mismatch issues.
|
|
28
|
-
|
|
29
|
-
## 7. "Where do the best practices and improvements come from?"
|
|
30
|
-
|
|
31
|
-
**The Process:** All improvements and best practices are based on:
|
|
32
|
-
|
|
33
|
-
- **Official React Documentation** - useSyncExternalStore for SSR, hooks rules, React 18/19 features
|
|
34
|
-
- **TypeScript Best Practices** - Type safety patterns, generics, strict mode
|
|
35
|
-
- **Security Standards** - OWASP for XSS prevention, AES-256-GCM encryption, RBAC patterns
|
|
36
|
-
- **Community Libraries** - Patterns from Zustand, Redux, Jotai for plugin architecture
|
|
37
|
-
- **Enterprise Patterns** - Error handling, multi-store isolation, GDPR compliance
|
|
38
|
-
|
|
39
|
-
Key fixes (like security isolation per-store, Immer optional loading) come from common issues in similar libraries.
|
|
40
|
-
|
|
41
|
-
---
|
|
42
|
-
|
|
43
|
-
## 🛑 Best Practices: Maximizing Reliability
|
|
44
|
-
|
|
45
|
-
1. **State Granularity**: Use RGS for global, persistent, or secured data. For transient UI state (like toggle transitions), standard `useState` is more appropriate.
|
|
46
|
-
2. **Namespace Management**: Always define a unique namespace for your store to prevent data collisions in shared domain environments.
|
|
47
|
-
3. **Rule Validation**: Ensure your RBAC rules are tested against your expected key patterns to maintain a robust security posture.
|
|
48
|
-
|
|
49
|
-
---
|
|
50
|
-
|
|
51
|
-
## 👋 Conclusion
|
|
52
|
-
|
|
53
|
-
RGS is designed for teams that prioritize long-term maintainability and system stability. By handling the complexities of security and persistence at the architectural level, we allow developers to focus on building features with confidence.
|
|
@@ -1,68 +0,0 @@
|
|
|
1
|
-
# ⚡ Chapter 2: Quick Start - From Zero to State in 30 Seconds
|
|
2
|
-
|
|
3
|
-
Stop wasting time on boilerplate. Here is how you deploy the RGS Panzer in your React project.
|
|
4
|
-
|
|
5
|
-
## 1. Installation
|
|
6
|
-
|
|
7
|
-
The engine is lightweight but armored.
|
|
8
|
-
|
|
9
|
-
```bash
|
|
10
|
-
npm install rgs
|
|
11
|
-
```
|
|
12
|
-
|
|
13
|
-
## 2. Initialization: The "Big Bang"
|
|
14
|
-
|
|
15
|
-
In your main entry file (e.g., `main.tsx` or `App.tsx`), wake up the engine once.
|
|
16
|
-
|
|
17
|
-
```typescript
|
|
18
|
-
import { initState, useStore } from '@biglogic/rgs';
|
|
19
|
-
|
|
20
|
-
// Initialize with optional settings
|
|
21
|
-
initState({
|
|
22
|
-
namespace: 'my-awesome-app',
|
|
23
|
-
persistence: true // Optional: Saves everything to localStorage automatically
|
|
24
|
-
});
|
|
25
|
-
```
|
|
26
|
-
|
|
27
|
-
## 3. Usage: Instant Reactions
|
|
28
|
-
|
|
29
|
-
Use the `useStore` hook. No providers, no wrappers. Just raw, atomic power.
|
|
30
|
-
|
|
31
|
-
```tsx
|
|
32
|
-
import { useStore } from '@biglogic/rgs';
|
|
33
|
-
|
|
34
|
-
function Counter() {
|
|
35
|
-
// If 'count' doesn't exist yet, it defaults to undefined. Easy.
|
|
36
|
-
const [count, setCount] = useStore<number>('count');
|
|
37
|
-
|
|
38
|
-
return (
|
|
39
|
-
<div className="card">
|
|
40
|
-
<h1>Power Level: {count ?? 0}</h1>
|
|
41
|
-
<button onClick={() => setCount((prev) => (prev || 0) + 1)}>
|
|
42
|
-
Boost Power 💥
|
|
43
|
-
</button>
|
|
44
|
-
</div>
|
|
45
|
-
);
|
|
46
|
-
}
|
|
47
|
-
```
|
|
48
|
-
|
|
49
|
-
## 🧐 What just happened?
|
|
50
|
-
|
|
51
|
-
- **Reactive Subscription**: `useStore('count')` tells React to watch the 'count' key. Surgical updates only.
|
|
52
|
-
- **Global Scope**: `setCount` updates the value everywhere in the app, instantly.
|
|
53
|
-
- **Resilient Nature**: If you access a key that hasn't been set yet, RGS returns `undefined` gracefully instead of throwing a tantrum.
|
|
54
|
-
|
|
55
|
-
## 🚨 Pro Tip: Direct Store Access
|
|
56
|
-
|
|
57
|
-
Need to access state outside of React components? Simple.
|
|
58
|
-
|
|
59
|
-
```typescript
|
|
60
|
-
import { getStore } from '@biglogic/rgs';
|
|
61
|
-
|
|
62
|
-
const value = getStore()?.get('count');
|
|
63
|
-
getStore()?.set('count', 9001);
|
|
64
|
-
```
|
|
65
|
-
|
|
66
|
-
---
|
|
67
|
-
|
|
68
|
-
**Next step:** [The Magnetar Way: One-Liner Power](03-the-magnetar-way.md)
|
|
@@ -1,146 +0,0 @@
|
|
|
1
|
-
# 🚀 Chapter 10: Local-First Sync Engine
|
|
2
|
-
|
|
3
|
-
RGS now includes a powerful **Local-First Sync Engine** that makes your app work offline by default and automatically synchronize when connectivity is restored.
|
|
4
|
-
|
|
5
|
-
## Why Local-First?
|
|
6
|
-
|
|
7
|
-
Traditional apps require an internet connection to work. Local-First apps work immediately with local data and sync in the background when possible.
|
|
8
|
-
|
|
9
|
-
### Benefits
|
|
10
|
-
|
|
11
|
-
- **Instant Load** - No waiting for server responses
|
|
12
|
-
- **Works Offline** - App functions without internet
|
|
13
|
-
- **Better UX** - No loading spinners for data
|
|
14
|
-
- **Conflict Resolution** - Smart merge strategies
|
|
15
|
-
|
|
16
|
-
## Quick Start
|
|
17
|
-
|
|
18
|
-
```typescript
|
|
19
|
-
import { gstate, useSyncedState } from '@biglogic/rgs'
|
|
20
|
-
|
|
21
|
-
// Create store with sync enabled
|
|
22
|
-
const store = gstate({
|
|
23
|
-
todos: [],
|
|
24
|
-
user: null
|
|
25
|
-
}, {
|
|
26
|
-
namespace: 'myapp',
|
|
27
|
-
sync: {
|
|
28
|
-
endpoint: 'https://api.example.com/sync',
|
|
29
|
-
// Use a getter function for secure token retrieval
|
|
30
|
-
authToken: () => localStorage.getItem('auth_token'),
|
|
31
|
-
autoSyncInterval: 30000, // Sync every 30s
|
|
32
|
-
syncOnReconnect: true // Auto-sync when back online
|
|
33
|
-
}
|
|
34
|
-
})
|
|
35
|
-
|
|
36
|
-
// Use in React components
|
|
37
|
-
function TodoList() {
|
|
38
|
-
const [todos, setTodos] = useSyncedState('todos')
|
|
39
|
-
|
|
40
|
-
// Add todo - automatically queued for sync
|
|
41
|
-
const addTodo = (text) => {
|
|
42
|
-
setTodos([...todos, { id: Date.now(), text }])
|
|
43
|
-
}
|
|
44
|
-
|
|
45
|
-
return <div>{/* ... */}</div>
|
|
46
|
-
}
|
|
47
|
-
```
|
|
48
|
-
|
|
49
|
-
## Configuration Options
|
|
50
|
-
|
|
51
|
-
| Option | Type | Default | Description |
|
|
52
|
-
|--------|------|---------|-------------|
|
|
53
|
-
| `endpoint` | `string` | required | Remote sync server URL |
|
|
54
|
-
| `authToken` | `string` or `() => string \| null` | - | Authentication token or getter function for secure retrieval |
|
|
55
|
-
| `strategy` | `string` | `'last-write-wins'` | Conflict resolution |
|
|
56
|
-
| `autoSyncInterval` | `number` | `30000` | Auto-sync interval (ms) |
|
|
57
|
-
| `syncOnReconnect` | `boolean` | `true` | Sync on network restore |
|
|
58
|
-
| `debounceTime` | `number` | `1000` | Batch changes (ms) |
|
|
59
|
-
| `maxRetries` | `number` | `3` | Failed sync retries |
|
|
60
|
-
| `onConflict` | `function` | - | Custom conflict handler |
|
|
61
|
-
| `onSync` | `function` | - | Sync completion callback |
|
|
62
|
-
|
|
63
|
-
## Conflict Resolution Strategies
|
|
64
|
-
|
|
65
|
-
### 1. Last-Write-Wins (Default)
|
|
66
|
-
|
|
67
|
-
```typescript
|
|
68
|
-
sync: { strategy: 'last-write-wins' }
|
|
69
|
-
```
|
|
70
|
-
Latest timestamp wins - simplest strategy.
|
|
71
|
-
|
|
72
|
-
### 2. Server-Wins
|
|
73
|
-
|
|
74
|
-
```typescript
|
|
75
|
-
sync: { strategy: 'server-wins' }
|
|
76
|
-
```
|
|
77
|
-
Always prefer remote values - useful for read-heavy apps.
|
|
78
|
-
|
|
79
|
-
### 3. Client-Wins
|
|
80
|
-
|
|
81
|
-
```typescript
|
|
82
|
-
sync: { strategy: 'client-wins' }
|
|
83
|
-
```
|
|
84
|
-
Always prefer local values - useful for write-heavy apps.
|
|
85
|
-
|
|
86
|
-
### 4. Custom Merge
|
|
87
|
-
|
|
88
|
-
```typescript
|
|
89
|
-
sync: {
|
|
90
|
-
strategy: 'merge',
|
|
91
|
-
onConflict: (conflict) => {
|
|
92
|
-
// Custom logic for merging
|
|
93
|
-
return {
|
|
94
|
-
action: 'merge',
|
|
95
|
-
value: { /* merged result */ }
|
|
96
|
-
}
|
|
97
|
-
}
|
|
98
|
-
}
|
|
99
|
-
```
|
|
100
|
-
|
|
101
|
-
## Hook API
|
|
102
|
-
|
|
103
|
-
### useSyncedState
|
|
104
|
-
|
|
105
|
-
```typescript
|
|
106
|
-
const [value, setValue, syncState] = useSyncedState('key')
|
|
107
|
-
|
|
108
|
-
// syncState contains:
|
|
109
|
-
// - isOnline: boolean
|
|
110
|
-
// - isSyncing: boolean
|
|
111
|
-
// - pendingChanges: number
|
|
112
|
-
// - conflicts: number
|
|
113
|
-
```
|
|
114
|
-
|
|
115
|
-
### useSyncStatus
|
|
116
|
-
|
|
117
|
-
```typescript
|
|
118
|
-
const status = useSyncStatus()
|
|
119
|
-
// Global sync status across all stores
|
|
120
|
-
```
|
|
121
|
-
|
|
122
|
-
## Manual Sync Control
|
|
123
|
-
|
|
124
|
-
```typescript
|
|
125
|
-
// Force sync
|
|
126
|
-
await store.plugins.sync.flush()
|
|
127
|
-
|
|
128
|
-
// Get sync state
|
|
129
|
-
const state = store.plugins.sync.getState()
|
|
130
|
-
```
|
|
131
|
-
|
|
132
|
-
## Integration with Persistence
|
|
133
|
-
|
|
134
|
-
The Sync Engine works seamlessly with RGS's existing persistence layer:
|
|
135
|
-
|
|
136
|
-
- **Local Storage** - Data persists locally first
|
|
137
|
-
- **IndexedDB** - For larger datasets
|
|
138
|
-
- **Cloud Sync** - Optional remote backup
|
|
139
|
-
|
|
140
|
-
Your data survives browser refresh, works offline, and stays synchronized across devices.
|
|
141
|
-
|
|
142
|
-
## Next Steps
|
|
143
|
-
|
|
144
|
-
- Learn about [Security Architecture](09-security-architecture.md)
|
|
145
|
-
- Explore [Plugin SDK](05-plugin-sdk.md)
|
|
146
|
-
- Check [Migration Guide](08-migration-guide.md)
|
|
@@ -1,284 +0,0 @@
|
|
|
1
|
-
# 8. Migration Guide
|
|
2
|
-
|
|
3
|
-
## Upgrading to v3.5.0 (The Type-Safe Era)
|
|
4
|
-
|
|
5
|
-
### New Feature: Selectors
|
|
6
|
-
v3.5.0 introduces **Function Selectors** for `useStore`. This is fully backward compatible, but we recommend migrating new code to this pattern for better type safety.
|
|
7
|
-
|
|
8
|
-
#### ✅ Recommended Pattern
|
|
9
|
-
```tsx
|
|
10
|
-
// Type-safe, autocomplete friendly
|
|
11
|
-
const userName = useStore(state => state.user.name)
|
|
12
|
-
```
|
|
13
|
-
|
|
14
|
-
#### 🟡 Legacy Pattern (Still Supported)
|
|
15
|
-
```tsx
|
|
16
|
-
// String-based, prone to typos
|
|
17
|
-
const [userName] = useStore('user_name')
|
|
18
|
-
```
|
|
19
|
-
|
|
20
|
-
---
|
|
21
|
-
|
|
22
|
-
## Upgrading to v3.4.0
|
|
23
|
-
|
|
24
|
-
### Performance Defaults
|
|
25
|
-
- **Size Limits**: `maxObjectSize` and `maxTotalSize` now default to `0` (disabled). If you relied on these warnings during development, explicitly enable them in `initState` or `gstate` options.
|
|
26
|
-
|
|
27
|
-
### Deprecations Removed
|
|
28
|
-
- `useGState` and `useSimpleState` have been removed. Replace all instances with `useStore`.
|
|
29
|
-
- `_registerMethod(name, fn)` support is removed from types (runtime warning remains). Update plugins to use `_registerMethod(pluginName, methodName, fn)`.
|
|
30
|
-
|
|
31
|
-
---
|
|
32
|
-
|
|
33
|
-
## Upgrading from Previous Versions
|
|
34
|
-
|
|
35
|
-
### Security: `secure` → `encoded`
|
|
36
|
-
|
|
37
|
-
**IMPORTANT:** The `secure` option has been deprecated in favor of `encoded` to clarify that it only applies **base64 encoding**, not encryption.
|
|
38
|
-
|
|
39
|
-
#### ❌ Old Code (Deprecated)
|
|
40
|
-
|
|
41
|
-
```typescript
|
|
42
|
-
store.set('apiKey', 'secret123', {
|
|
43
|
-
persist: true,
|
|
44
|
-
secure: true // ⚠️ DEPRECATED: This is NOT encryption!
|
|
45
|
-
})
|
|
46
|
-
```
|
|
47
|
-
|
|
48
|
-
#### ✅ New Code (Recommended)
|
|
49
|
-
|
|
50
|
-
```typescript
|
|
51
|
-
store.set('apiKey', 'secret123', {
|
|
52
|
-
persist: true,
|
|
53
|
-
encoded: true // ✅ Clear: This is base64 encoding
|
|
54
|
-
})
|
|
55
|
-
```
|
|
56
|
-
|
|
57
|
-
#### Backward Compatibility
|
|
58
|
-
|
|
59
|
-
Your old code will **still work**, but you'll see a deprecation warning in TypeScript:
|
|
60
|
-
|
|
61
|
-
```typescript
|
|
62
|
-
/** @deprecated Use 'encoded' instead. 'secure' only applies base64 encoding, not encryption. */
|
|
63
|
-
secure?: boolean
|
|
64
|
-
```
|
|
65
|
-
|
|
66
|
-
#### Why This Change?
|
|
67
|
-
|
|
68
|
-
Base64 encoding is **NOT encryption**. It's trivial to decode:
|
|
69
|
-
|
|
70
|
-
```javascript
|
|
71
|
-
// Anyone can decode base64
|
|
72
|
-
const encoded = btoa(JSON.stringify({ secret: 'password123' }))
|
|
73
|
-
const decoded = JSON.parse(atob(encoded)) // { secret: 'password123' }
|
|
74
|
-
```
|
|
75
|
-
|
|
76
|
-
**For real security**, use proper encryption libraries like:
|
|
77
|
-
|
|
78
|
-
- `crypto-js` (AES encryption)
|
|
79
|
-
- `tweetnacl` (NaCl encryption)
|
|
80
|
-
- Web Crypto API (`crypto.subtle`)
|
|
81
|
-
|
|
82
|
-
---
|
|
83
|
-
|
|
84
|
-
### Error Handling: `onError` Callback
|
|
85
|
-
|
|
86
|
-
**NEW:** You can now catch and handle errors from plugins, hydration, and other operations.
|
|
87
|
-
|
|
88
|
-
#### Example: Custom Error Logging
|
|
89
|
-
|
|
90
|
-
```typescript
|
|
91
|
-
import { initState, useStore } from '@biglogic/rgs'
|
|
92
|
-
|
|
93
|
-
const store = initState({
|
|
94
|
-
namespace: 'myapp',
|
|
95
|
-
onError: (error, context) => {
|
|
96
|
-
// Send to your error tracking service
|
|
97
|
-
console.error(`[gState Error] ${context.operation}:`, error)
|
|
98
|
-
|
|
99
|
-
if (context.operation === 'hydration') {
|
|
100
|
-
// Handle corrupted localStorage
|
|
101
|
-
localStorage.clear()
|
|
102
|
-
alert('Storage corrupted, resetting...')
|
|
103
|
-
}
|
|
104
|
-
|
|
105
|
-
if (context.operation.startsWith('plugin:')) {
|
|
106
|
-
// Handle plugin crashes
|
|
107
|
-
Sentry.captureException(error, { tags: { plugin: context.operation } })
|
|
108
|
-
}
|
|
109
|
-
}
|
|
110
|
-
})
|
|
111
|
-
```
|
|
112
|
-
|
|
113
|
-
#### Error Context
|
|
114
|
-
|
|
115
|
-
```typescript
|
|
116
|
-
interface ErrorContext {
|
|
117
|
-
operation: string // 'hydration', 'plugin:name:hook', 'set'
|
|
118
|
-
key?: string // State key (if applicable)
|
|
119
|
-
}
|
|
120
|
-
```
|
|
121
|
-
|
|
122
|
-
---
|
|
123
|
-
|
|
124
|
-
### Performance: `maxObjectSize` Warning
|
|
125
|
-
|
|
126
|
-
**NEW:** Get warned when storing objects larger than a configurable limit (default: 5MB).
|
|
127
|
-
|
|
128
|
-
#### Example: Custom Size Limit
|
|
129
|
-
|
|
130
|
-
```typescript
|
|
131
|
-
import { createStore } from '@biglogic/rgs'
|
|
132
|
-
|
|
133
|
-
const store = createStore({
|
|
134
|
-
maxObjectSize: 10 * 1024 * 1024, // 10MB limit
|
|
135
|
-
onError: (error, context) => {
|
|
136
|
-
if (context.operation === 'set') {
|
|
137
|
-
console.warn(`Large object detected in key: ${context.key}`)
|
|
138
|
-
}
|
|
139
|
-
}
|
|
140
|
-
})
|
|
141
|
-
|
|
142
|
-
// This will trigger a warning if > 10MB
|
|
143
|
-
store.set('bigData', hugeArray)
|
|
144
|
-
```
|
|
145
|
-
|
|
146
|
-
#### Disable Size Checking
|
|
147
|
-
|
|
148
|
-
```typescript
|
|
149
|
-
const store = createStore({
|
|
150
|
-
maxObjectSize: 0 // Disable size warnings
|
|
151
|
-
})
|
|
152
|
-
```
|
|
153
|
-
|
|
154
|
-
---
|
|
155
|
-
|
|
156
|
-
## Upgrading to Latest Version (The Enterprise Update)
|
|
157
|
-
|
|
158
|
-
**IMPORTANT:** This release introduces a fundamental shift towards **Multi-Store Isolation**. Security rules and GDPR consents are now instance-bound rather than global.
|
|
159
|
-
|
|
160
|
-
### 1. Security: Global → Instance-Specific
|
|
161
|
-
|
|
162
|
-
In previous versions, security rules were shared globally. Now, each store instance maintains its own rules for better isolation in micro-frontend environments.
|
|
163
|
-
|
|
164
|
-
#### ❌ Deprecated Global Methods
|
|
165
|
-
|
|
166
|
-
```typescript
|
|
167
|
-
import { addAccessRule, recordConsent } from '@biglogic/rgs'
|
|
168
|
-
|
|
169
|
-
// ⚠️ DEPRECATED: These affect the 'default' store only and are less isolated
|
|
170
|
-
addAccessRule('user_*', ['read', 'write'])
|
|
171
|
-
```
|
|
172
|
-
|
|
173
|
-
#### ✅ Recommended Instance Methods
|
|
174
|
-
|
|
175
|
-
```typescript
|
|
176
|
-
const store = createStore({ namespace: 'my-isolated-app' })
|
|
177
|
-
|
|
178
|
-
// ✅ Use the instance methods
|
|
179
|
-
store.addAccessRule('user_*', ['read', 'write'])
|
|
180
|
-
store.recordConsent('user123', 'marketing', true)
|
|
181
|
-
```
|
|
182
|
-
|
|
183
|
-
### 2. Operational Resilience: Ghost Stores
|
|
184
|
-
|
|
185
|
-
**NEW:** If you access a store that hasn't finished its initialization (e.g., during slow hydration), RGS now returns a **Ghost Store Proxy**.
|
|
186
|
-
|
|
187
|
-
- **Behavior:** It prevents application crashes by providing a safe fallback.
|
|
188
|
-
- **Developer Warning:** It logs a detailed warning in the console so you can fix the initialization sequence.
|
|
189
|
-
|
|
190
|
-
### 3. Performance: Regex Caching
|
|
191
|
-
|
|
192
|
-
**NEW:** Permission checks now use an internal **Regex Cache** per instance.
|
|
193
|
-
|
|
194
|
-
- **Why?** Avoids the overhead of re-compiling regex strings on every `.get()` or `.set()` call.
|
|
195
|
-
- **Impact:** Significant performance boost for applications with high-frequency state updates and complex RBAC rules.
|
|
196
|
-
|
|
197
|
-
### 4. Advanced Plugin Typing
|
|
198
|
-
|
|
199
|
-
**NEW:** Introducing `GStatePlugins` for Module Augmentation.
|
|
200
|
-
|
|
201
|
-
- You can now define types for your custom plugins to get full IDE autocomplete.
|
|
202
|
-
|
|
203
|
-
---
|
|
204
|
-
|
|
205
|
-
## v2.9.5: The Architecture & Safety Update (2026-02-16)
|
|
206
|
-
|
|
207
|
-
This release focuses on improving developer ergonomics, security visibility, and complex dependency handling.
|
|
208
|
-
|
|
209
|
-
### 1. Nested Computed Dependencies
|
|
210
|
-
|
|
211
|
-
**NEW:** Computed values can now re-trigger based on other computed values.
|
|
212
|
-
|
|
213
|
-
```typescript
|
|
214
|
-
store.compute('tax', (get) => (get<number>('subtotal') || 0) * 0.2)
|
|
215
|
-
store.compute('total', (get) => (get<number>('subtotal') || 0) + (get<number>('tax') || 0))
|
|
216
|
-
```
|
|
217
|
-
|
|
218
|
-
### 2. Direct Store Access: `getStore()`
|
|
219
|
-
**NEW:** A top-level utility to retrieve the default store without React hooks.
|
|
220
|
-
|
|
221
|
-
```typescript
|
|
222
|
-
import { getStore } from '@biglogic/rgs'
|
|
223
|
-
|
|
224
|
-
export const toggleTheme = () => {
|
|
225
|
-
const store = getStore()
|
|
226
|
-
if (store) store.set('mode', 'dark')
|
|
227
|
-
}
|
|
228
|
-
```
|
|
229
|
-
|
|
230
|
-
### 3. Exposed Metadata: `namespace` and `userId`
|
|
231
|
-
**NEW:** Store instances now expose their identifying properties as read-only getters.
|
|
232
|
-
|
|
233
|
-
```typescript
|
|
234
|
-
const store = createStore({ namespace: 'auth-vault', userId: 'user-001' })
|
|
235
|
-
console.log(store.namespace) // 'auth-vault'
|
|
236
|
-
console.log(store.userId) // 'user-001'
|
|
237
|
-
```
|
|
238
|
-
|
|
239
|
-
### 4. High-Volume & Hybrid Sync (Plugins)
|
|
240
|
-
**NEW:** Support for GB-scale storage and Remote Cloud Backups.
|
|
241
|
-
|
|
242
|
-
- **IndexedDB Plugin**: Replaces localStorage for massive browser datasets.
|
|
243
|
-
- **Cloud Sync Plugin**: Differential synchronization to MongoDB, Firebase, or any SQL backend.
|
|
244
|
-
|
|
245
|
-
```typescript
|
|
246
|
-
// Example: Manual Cloud Sync
|
|
247
|
-
const result = await store.plugins.cloudSync.sync()
|
|
248
|
-
console.log('Stats:', store.plugins.cloudSync.getStats())
|
|
249
|
-
```
|
|
250
|
-
|
|
251
|
-
---
|
|
252
|
-
|
|
253
|
-
## Breaking Changes
|
|
254
|
-
|
|
255
|
-
### 🔒 Security Isolation
|
|
256
|
-
|
|
257
|
-
If you relied on `addAccessRule()` from the global export to affect a `createStore()` instance, you must now call `store.addAccessRule()` on that specific instance.
|
|
258
|
-
|
|
259
|
-
---
|
|
260
|
-
|
|
261
|
-
## Recommended Actions
|
|
262
|
-
|
|
263
|
-
### 1. Migrate Security Calls to Store Instances
|
|
264
|
-
|
|
265
|
-
**Priority:** High (if using multiple stores)
|
|
266
|
-
|
|
267
|
-
**Effort:** Low
|
|
268
|
-
|
|
269
|
-
### 2. Implement `GStatePlugins` for Custom Plugins
|
|
270
|
-
|
|
271
|
-
**Priority:** Medium (Developer Experience)
|
|
272
|
-
|
|
273
|
-
**Effort:** Low
|
|
274
|
-
|
|
275
|
-
---
|
|
276
|
-
|
|
277
|
-
## Need Help?
|
|
278
|
-
|
|
279
|
-
- **Issues:** [GitHub Issues](https://github.com/@biglogic/rgs/issues)
|
|
280
|
-
- **Docs:** [Galaxy Documentation](../SUMMARY.md)
|
|
281
|
-
|
|
282
|
-
---
|
|
283
|
-
|
|
284
|
-
## Last updated: 2026-02-16
|