@umituz/react-native-storage 2.6.23 → 2.6.24

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 ADDED
@@ -0,0 +1,137 @@
1
+ # React Native Storage
2
+
3
+ Unified storage solution for React Native with AsyncStorage persistence, Zustand state management, and in-memory caching.
4
+
5
+ ## Overview
6
+
7
+ Complete storage and caching solution following Domain-Driven Design principles. Located at `src/`.
8
+
9
+ ## Features
10
+
11
+ - **AsyncStorage Integration** - Type-safe storage operations
12
+ - **Zustand State Management** - Persisted stores with factory pattern
13
+ - **In-Memory Cache** - TTL, LRU, LFU, FIFO eviction strategies
14
+ - **React Hooks** - Simple and powerful API for React integration
15
+ - **Type-Safe** - Full TypeScript support with generics
16
+ - **Domain-Driven Design** - Clean Architecture implementation
17
+ - **Result Pattern** - Type-safe error handling without exceptions
18
+
19
+ ## Installation
20
+
21
+ Install the package and required dependencies:
22
+
23
+ ```bash
24
+ npm install @umituz/react-native-storage
25
+ npm install @react-native-async-storage/async-storage zustand
26
+ ```
27
+
28
+ For Expo projects:
29
+
30
+ ```bash
31
+ npx expo install @react-native-async-storage/async-storage zustand
32
+ ```
33
+
34
+ ## Documentation
35
+
36
+ For detailed documentation, refer to module READMEs:
37
+
38
+ - [Cache Module](./src/cache/README.md) - In-memory cache system
39
+ - [React Hooks](./src/presentation/hooks/README.md) - All React hooks
40
+ - [Domain Layer](./src/domain/README.md) - Business logic and entities
41
+ - [Infrastructure Layer](./src/infrastructure/README.md) - AsyncStorage integration
42
+ - [Application Layer](./src/application/README.md) - Ports and interfaces
43
+
44
+ ## Architecture
45
+
46
+ Clean Architecture with DDD principles:
47
+
48
+ ```
49
+ ┌─────────────────────────────────────────┐
50
+ │ Presentation Layer │
51
+ │ (React Hooks, Components) │
52
+ └─────────────────────────────────────────┘
53
+
54
+ ┌─────────────────────────────────────────┐
55
+ │ Application Layer │
56
+ │ (Use Cases, Ports) │
57
+ └─────────────────────────────────────────┘
58
+
59
+ ┌─────────────────────────────────────────┐
60
+ │ Domain Layer │
61
+ │ (Business Logic, Entities) │
62
+ └─────────────────────────────────────────┘
63
+
64
+ ┌─────────────────────────────────────────┐
65
+ │ Infrastructure Layer │
66
+ │ (AsyncStorage, MMKV) │
67
+ └─────────────────────────────────────────┘
68
+ ```
69
+
70
+ ## Module Structure
71
+
72
+ ### Storage Hooks
73
+ Located at `src/presentation/hooks/`
74
+ - `useStorage()` - AsyncStorage operations
75
+ - `useStorageState(key, initial)` - State with storage sync
76
+ - `useStore(store, selector)` - Zustand store hook
77
+
78
+ ### Cache Hooks
79
+ Located at `src/presentation/hooks/`
80
+ - `useCache(name, config)` - In-memory cache instance
81
+ - `useCachedValue(key, fetcher, ttl)` - Single value caching
82
+ - `usePersistentCache(key, fetcher, opts)` - API caching with persistence
83
+ - `useCacheState()` - Cache state integration
84
+
85
+ ### Storage Operations
86
+ Located at `src/infrastructure/repositories/`
87
+ - `getItem(key, default)` - Retrieve value with default
88
+ - `setItem(key, value)` - Store value
89
+ - `getString(key, default)` - Retrieve string value
90
+ - `setString(key, value)` - Store string value
91
+ - `removeItem(key)` - Delete value
92
+ - `hasItem(key)` - Check existence
93
+ - `clearAll()` - Clear all storage
94
+
95
+ ### Cache Operations
96
+ Located at `src/cache/infrastructure/`
97
+ - `new Cache(config)` - Create cache instance
98
+ - `cache.set(key, value, ttl)` - Add value with TTL
99
+ - `cache.get(key)` - Retrieve value
100
+ - `cache.has(key)` - Check existence
101
+ - `cache.delete(key)` - Delete entry
102
+ - `cache.clear()` - Clear all entries
103
+ - `cache.invalidatePattern(pattern)` - Pattern-based invalidation
104
+ - `cache.getStats()` - Get cache statistics
105
+
106
+ ### Store Factory
107
+ Located at `src/domain/factories/`
108
+ - `createStore(config)` - Create Zustand store with persistence
109
+ - Support for actions, persist middleware, versioning
110
+
111
+ ## Error Handling
112
+
113
+ All operations use Result pattern for type-safe error handling:
114
+
115
+ ```typescript
116
+ type StorageResult<T> =
117
+ | { success: true; data: T }
118
+ | { success: false; error: StorageError }
119
+ ```
120
+
121
+ Check `success` property before accessing `data` or `error`.
122
+
123
+ ## Type Safety
124
+
125
+ Full TypeScript support with generic type parameters:
126
+
127
+ - Storage operations: `getItem<User>(key, defaultValue)`
128
+ - Cache operations: `new Cache<Product>(config)`
129
+ - Store state: Type-inferred from initial state
130
+
131
+ ## License
132
+
133
+ MIT © [Ümit UZ](https://github.com/umituz)
134
+
135
+ ## GitHub
136
+
137
+ [https://github.com/umituz/react-native-storage](https://github.com/umituz/react-native-storage)
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@umituz/react-native-storage",
3
- "version": "2.6.23",
3
+ "version": "2.6.24",
4
4
  "description": "Unified storage solution with AsyncStorage persistence, Zustand state management, and in-memory caching for React Native",
5
5
  "main": "./src/index.ts",
6
6
  "types": "./src/index.ts",
@@ -57,6 +57,7 @@
57
57
  },
58
58
  "files": [
59
59
  "src",
60
+ "examples",
60
61
  "README.md",
61
62
  "LICENSE"
62
63
  ]
package/src/README.md ADDED
@@ -0,0 +1,185 @@
1
+ # Source Directory
2
+
3
+ Main source code for react-native-storage package following Domain-Driven Design principles.
4
+
5
+ ## Overview
6
+
7
+ Complete implementation of storage and caching solution with Clean Architecture. Located at `src/`.
8
+
9
+ ## Architecture
10
+
11
+ Clean Architecture with DDD principles:
12
+ - `application/` - Application layer (ports/interfaces)
13
+ - `cache/` - In-memory caching module
14
+ - `domain/` - Domain layer (business logic)
15
+ - `infrastructure/` - Infrastructure layer (implementations)
16
+ - `presentation/` - Presentation layer (React hooks)
17
+ - `types/` - Shared TypeScript types
18
+
19
+ ## Strategies
20
+
21
+ ### Layer Organization
22
+ - Use application layer for interfaces and ports
23
+ - Use domain layer for business logic and entities
24
+ - Use infrastructure layer for external service implementations
25
+ - Use presentation layer for React integration
26
+ - Use cache module for in-memory caching
27
+
28
+ ### Dependency Flow
29
+ - Presentation depends on domain
30
+ - Domain depends on nothing (core)
31
+ - Infrastructure implements domain interfaces
32
+ - Application defines contracts between layers
33
+
34
+ ### Module Separation
35
+ - Keep cache module independent and self-contained
36
+ - Enable cache usage without storage dependency
37
+ - Support standalone cache operations
38
+ - Maintain clean module boundaries
39
+
40
+ ### Type Safety
41
+ - Use TypeScript for all modules
42
+ - Provide generic type parameters
43
+ - Enable type inference
44
+ - Support branded types for storage keys
45
+
46
+ ## Restrictions
47
+
48
+ ### Layer Dependencies
49
+ - DO NOT import infrastructure in domain layer
50
+ - DO NOT import presentation in domain layer
51
+ - DO NOT import application in infrastructure
52
+ - DO NOT create circular dependencies
53
+
54
+ ### Module Boundaries
55
+ - DO NOT mix concerns across layers
56
+ - DO NOT bypass layer boundaries
57
+ - DO NOT expose implementation details
58
+ - DO NOT create tight coupling between modules
59
+
60
+ ### Code Organization
61
+ - DO NOT place business logic in presentation
62
+ - DO NOT place UI code in domain
63
+ - DO NOT place external dependencies in domain
64
+ - DO NOT create god objects
65
+
66
+ ### Architecture Compliance
67
+ - DO NOT violate dependency inversion principle
68
+ - DO NOT ignore layer responsibilities
69
+ - DO NOT create ambiguous module placement
70
+ - DO NOT mix abstraction levels
71
+
72
+ ## Rules
73
+
74
+ ### Application Layer
75
+ - MUST define IStorageRepository interface
76
+ - MUST provide ports for dependency inversion
77
+ - MUST not contain implementation details
78
+ - MUST be framework-agnostic
79
+ - MUST enable constructor injection
80
+
81
+ ### Cache Module
82
+ - MUST provide domain entities (CacheManager, CachedValue)
83
+ - MUST provide infrastructure implementation (TTLCache)
84
+ - MUST provide presentation hooks (useCache, useCachedValue)
85
+ - MUST support multiple eviction strategies (LRU, LFU, FIFO, TTL)
86
+ - MUST be independent and self-contained
87
+
88
+ ### Domain Layer
89
+ - MUST contain core business logic
90
+ - MUST define value objects (StorageKey)
91
+ - MUST define entities (CachedValue, Result)
92
+ - MUST provide factory functions (createStore)
93
+ - MUST define error types (StorageError hierarchy)
94
+ - MUST not depend on external frameworks
95
+
96
+ ### Infrastructure Layer
97
+ - MUST implement IStorageRepository interface
98
+ - MUST provide StorageService adapter for Zustand
99
+ - MUST handle Result pattern for error handling
100
+ - MUST support AsyncStorage as primary backend
101
+ - MUST enable custom storage backends
102
+
103
+ ### Presentation Layer
104
+ - MUST provide React hooks for storage
105
+ - MUST provide React hooks for cache
106
+ - MUST enable reactive state management
107
+ - MUST handle loading and error states
108
+ - MUST follow React hooks rules
109
+
110
+ ### Types Module
111
+ - MUST provide shared TypeScript types
112
+ - MUST define StorageResult type
113
+ - MUST define DynamicStorageKey type
114
+ - MUST enable type-safe operations
115
+ - MUST be imported by all layers
116
+
117
+ ### Export Structure
118
+ - MUST export from index.ts at root level
119
+ - MUST organize exports by module
120
+ - MUST provide TypeScript types
121
+ - MUST maintain backward compatibility
122
+ - MUST not export internal utilities
123
+
124
+ ### File Organization
125
+ - MUST place files in appropriate layer
126
+ - MUST follow feature-based organization within layers
127
+ - MUST use descriptive file names
128
+ - MUST maintain consistent structure
129
+ - MUST enable easy navigation
130
+
131
+ ### Testing Structure
132
+ - MUST place tests in __tests__ directories
133
+ - MUST mirror source structure
134
+ - MUST provide comprehensive coverage
135
+ - MUST enable isolated testing
136
+ - MUST not depend on external services
137
+
138
+ ### Type Safety Requirements
139
+ - MUST use TypeScript for all files
140
+ - MUST provide generic type parameters
141
+ - MUST enable type inference
142
+ - MUST not use `any` type
143
+ - MUST enforce strict type checking
144
+
145
+ ### Error Handling
146
+ - MUST use Result pattern for operations
147
+ - MUST preserve error context
148
+ - MUST provide hierarchical error types
149
+ - MUST not throw exceptions across layers
150
+ - MUST handle errors gracefully
151
+
152
+ ### Documentation
153
+ - MUST provide README for each layer
154
+ - MUST document public APIs
155
+ - MUST specify file locations
156
+ - MUST explain architecture decisions
157
+ - MUST not include code examples in README files
158
+
159
+ ### Naming Conventions
160
+ - MUST use camelCase for files and variables
161
+ - MUST use PascalCase for types and interfaces
162
+ - MUST use descriptive names
163
+ - MUST follow React hooks naming (use prefix)
164
+ - MUST maintain consistency across modules
165
+
166
+ ### Performance Considerations
167
+ - MUST optimize for read-heavy or write-heavy patterns
168
+ - MUST minimize unnecessary re-renders
169
+ - MUST use memoization where appropriate
170
+ - MUST enable lazy loading
171
+ - MUST consider bundle size impact
172
+
173
+ ### Security Requirements
174
+ - MUST not expose sensitive data in logs
175
+ - MUST use SecureStore for sensitive data
176
+ - MUST handle encryption for secure storage
177
+ - MUST validate input data
178
+ - MUST prevent injection attacks
179
+
180
+ ### Best Practices Compliance
181
+ - MUST follow Single Responsibility Principle
182
+ - MUST follow Open/Closed Principle
183
+ - MUST follow Liskov Substitution Principle
184
+ - MUST follow Interface Segregation Principle
185
+ - MUST follow Dependency Inversion Principle
@@ -0,0 +1,158 @@
1
+ # Application Layer
2
+
3
+ Ports and interfaces for dependency inversion between domain and infrastructure layers.
4
+
5
+ ## Overview
6
+
7
+ Application layer containing interfaces (ports) for storage operations. Located at `src/application/`.
8
+
9
+ ## Directory Structure
10
+
11
+ - `ports/` - Repository interfaces defining storage contracts
12
+
13
+ ## Strategies
14
+
15
+ ### Dependency Inversion
16
+ - Use IStorageRepository interface for storage operations
17
+ - Define contracts in application layer
18
+ - Implement interfaces in infrastructure layer
19
+ - Enable dependency injection for testing
20
+
21
+ ### Port Definition
22
+ - Use IStorageRepository as primary storage interface
23
+ - Define all storage operations as methods
24
+ - Support Result pattern for error handling
25
+ - Enable generic type parameters for type safety
26
+
27
+ ### Use Case Pattern
28
+ - Create use cases for complex business logic
29
+ - Inject IStorageRepository through constructor
30
+ - Encapsulate business rules in use case methods
31
+ - Enable testing with mock implementations
32
+
33
+ ### Interface Segregation
34
+ - Define cohesive interfaces for specific purposes
35
+ - Support granular method dependencies
36
+ - Enable single responsibility principle
37
+ - Facilitate testing with focused mocks
38
+
39
+ ## Restrictions
40
+
41
+ ### Interface Definition
42
+ - DO NOT define implementation details in interfaces
43
+ - DO NOT create interfaces without clear purpose
44
+ - DO NOT mix different concerns in single interface
45
+ - DO NOT include framework-specific types
46
+
47
+ ### Dependency Injection
48
+ - DO NOT create concrete instances in use cases
49
+ - DO NOT use hardcoded dependencies
50
+ - DO NOT skip constructor injection
51
+ - DO NOT create circular dependencies
52
+
53
+ ### Use Case Implementation
54
+ - DO NOT implement business logic in components
55
+ - DO NOT mix storage operations with UI logic
56
+ - DO NOT create use cases without clear purpose
57
+ - DO NOT bypass error handling in use cases
58
+
59
+ ### Testing
60
+ - DO NOT test with real storage implementations
61
+ - DO NOT create complex mock implementations
62
+ - DO NOT share state between tests
63
+ - DO NOT forget to reset mocks between tests
64
+
65
+ ## Rules
66
+
67
+ ### IStorageRepository Interface
68
+ - MUST define getItem<T>(key, defaultValue): Promise<StorageResult<T>>
69
+ - MUST define setItem<T>(key, value): Promise<StorageResult<void>>
70
+ - MUST define getString(key, defaultValue): Promise<StorageResult<string>>
71
+ - MUST define setString(key, value): Promise<StorageResult<void>>
72
+ - MUST define removeItem(key): Promise<StorageResult<void>>
73
+ - MUST define hasItem(key): Promise<boolean>
74
+ - MUST define clearAll(): Promise<StorageResult<void>>
75
+
76
+ ### Interface Design
77
+ - MUST use generic type parameters for value operations
78
+ - MUST return Result type for all mutable operations
79
+ - MUST support type inference from parameters
80
+ - MUST be framework-agnostic
81
+ - MUST define contracts only (no implementation)
82
+
83
+ ### Method Signatures
84
+ - MUST accept key parameter for all operations
85
+ - MUST accept defaultValue parameter for get operations
86
+ - MUST accept value parameter for set operations
87
+ - MUST return Promise for all async operations
88
+ - MUST include StorageResult for typed results
89
+
90
+ ### Use Case Implementation
91
+ - MUST accept IStorageRepository in constructor
92
+ - MUST define single responsibility per use case
93
+ - MUST handle Result pattern in all operations
94
+ - MUST return domain types from use case methods
95
+ - MUST not expose storage implementation details
96
+
97
+ ### Constructor Injection
98
+ - MUST inject dependencies through constructor
99
+ - MUST store dependencies as private fields
100
+ - MUST use interface types for dependencies
101
+ - MUST enable dependency injection for testing
102
+ - MUST not create instances inside use cases
103
+
104
+ ### Error Handling
105
+ - MUST check result.success before accessing data
106
+ - MUST handle result.error appropriately
107
+ - MUST propagate errors to callers when needed
108
+ - MUST not throw exceptions from use cases
109
+ - MUST preserve error context
110
+
111
+ ### Testing Requirements
112
+ - MUST enable mocking of IStorageRepository
113
+ - MUST support test double implementations
114
+ - MUST isolate tests from real storage
115
+ - MUST clear state between test runs
116
+ - MUST not depend on external services
117
+
118
+ ### Mock Implementation
119
+ - MUST implement full IStorageRepository interface
120
+ - MUST return appropriate Result types
121
+ - MUST simulate storage behavior accurately
122
+ - MUST support async operations with Promise
123
+ - MUST be simple and predictable
124
+
125
+ ### Custom Repository Implementation
126
+ - MUST implement IStorageRepository interface
127
+ - MUST use Result pattern for all methods
128
+ - MUST handle errors appropriately
129
+ - MUST support generic type parameters
130
+ - MUST be compatible with existing code
131
+
132
+ ### Layer Separation
133
+ - MUST not depend on infrastructure implementations
134
+ - MUST not depend on presentation components
135
+ - MUST define contracts for domain use
136
+ - MUST enable layer independence
137
+ - MUST support testing at each layer
138
+
139
+ ### Export Rules
140
+ - MUST export IStorageRepository interface
141
+ - MUST export all port interfaces
142
+ - MUST not export implementations
143
+ - MUST provide TypeScript types
144
+ - MUST document interface contracts
145
+
146
+ ### Architecture Compliance
147
+ - MUST follow dependency inversion principle
148
+ - MUST depend on abstractions not concretions
149
+ - MUST enable independent layer evolution
150
+ - MUST support multiple implementations
151
+ - MUST maintain clear separation of concerns
152
+
153
+ ### Documentation
154
+ - MUST document all interface methods
155
+ - MUST specify method contracts clearly
156
+ - MUST provide usage guidance
157
+ - MUST explain Result pattern usage
158
+ - MUST not include implementation examples
@@ -0,0 +1,127 @@
1
+ # Application Ports
2
+
3
+ Repository interfaces for dependency inversion and testability.
4
+
5
+ ## Overview
6
+
7
+ Ports define contracts between application and infrastructure layers using dependency inversion principle. Located at `src/application/ports/`.
8
+
9
+ ## Strategies
10
+
11
+ ### Dependency Inversion
12
+ - Define interfaces in application layer
13
+ - Implement interfaces in infrastructure layer
14
+ - Depend on abstractions, not concretions
15
+ - Enable swapping implementations without business logic changes
16
+
17
+ ### Testability Strategy
18
+ - Design interfaces for easy mocking
19
+ - Use constructor injection for dependencies
20
+ - Create fake implementations for testing
21
+ - Separate unit tests from integration tests
22
+
23
+ ### Contract Design
24
+ - Define clear method signatures
25
+ - Use Result pattern for error handling
26
+ - Include type parameters for flexibility
27
+ - Document interface contracts
28
+
29
+ ### Implementation Strategy
30
+ - Provide production implementation (AsyncStorage)
31
+ - Provide mock implementation for testing
32
+ - Support custom implementations (MMKV, SecureStore)
33
+ - Allow platform-specific implementations
34
+
35
+ ## Restrictions
36
+
37
+ ### Interface Design
38
+ - DO NOT include implementation details in interfaces
39
+ - DO NOT change interface signatures without major version bump
40
+ - DO NOT add optional parameters to existing methods
41
+ - DO NOT remove methods from interfaces
42
+
43
+ ### Usage
44
+ - DO NOT use concrete implementations in business logic
45
+ - DO NOT instantiate dependencies inside services
46
+ - DO NOT couple services to specific storage technologies
47
+ - DO NOT bypass interface for performance
48
+
49
+ ### Implementation
50
+ - DO NOT throw exceptions from interface methods
51
+ - DO NOT return undefined (use null or Result)
52
+ - DO NOT ignore type parameters
53
+ - DO NOT mix sync and async patterns
54
+
55
+ ### Testing
56
+ - DO NOT use real storage in unit tests
57
+ - DO NOT share mock instances between tests
58
+ - DO NOT forget to reset mock state
59
+ - DO NOT test interfaces directly
60
+
61
+ ## Rules
62
+
63
+ ### Interface Definition
64
+ - MUST define all required methods
65
+ - MUST use generic type parameters for flexibility
66
+ - MUST return Promise for async operations
67
+ - MUST use Result pattern for error handling
68
+
69
+ ### Method Signatures
70
+ - MUST include type parameter <T> for data operations
71
+ - MUST accept key parameter for storage operations
72
+ - MUST provide defaultValue for getItem methods
73
+ - MUST return StorageResult for operations that can fail
74
+
75
+ ### Constructor Injection
76
+ - MUST inject interfaces through constructors
77
+ - MUST store interface reference as private field
78
+ - MUST mark constructor parameter as readonly
79
+ - MUST not create instances inside class
80
+
81
+ ### Implementation Classes
82
+ - MUST implement complete interface
83
+ - MUST handle all error cases internally
84
+ - MUST return appropriate error types
85
+ - MUST log errors for debugging
86
+
87
+ ### Mock Implementations
88
+ - MUST implement all interface methods
89
+ - MUST provide methods to set mock behavior
90
+ - MUST track method calls for assertions
91
+ - MUST reset state between tests
92
+
93
+ ### Custom Implementations
94
+ - MUST implement IStorageRepository interface
95
+ - MUST handle serialization consistently
96
+ - MUST provide error details in results
97
+ - MUST document platform limitations
98
+
99
+ ### Dependency Injection
100
+ - MUST use interface types in constructors
101
+ - MUST not depend on concrete classes
102
+ - MUST support different implementations
103
+ - MUST validate dependencies at construction time
104
+
105
+ ### Type Safety
106
+ - MUST specify type parameters for all operations
107
+ - MUST enforce type consistency
108
+ - MUST use type guards for validation
109
+ - MUST avoid type assertions
110
+
111
+ ### Error Handling
112
+ - MUST return failure Result for errors
113
+ - MUST include error context (key, operation)
114
+ - MUST preserve original error as cause
115
+ - MUST not throw exceptions from interface methods
116
+
117
+ ### Testing Strategy
118
+ - MUST use mock implementations for unit tests
119
+ - MUST use real implementations for integration tests
120
+ - MUST reset state in test setup
121
+ - MUST test error scenarios
122
+
123
+ ### Documentation
124
+ - MUST document interface contracts
125
+ - MUST specify error types for each method
126
+ - MUST include parameter descriptions
127
+ - MUST provide usage examples in tests