synstate 3.0.3 → 3.0.4

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 CHANGED
@@ -17,7 +17,7 @@
17
17
 
18
18
  "SynState" is named after "Synchronized + State." It represents a sound synchronized state through a **glitch-free**[^1] Observable implementation.
19
19
 
20
- [^1]: See ["How SynState solved the glitch?"](https://noshiro-pf.github.io/synstate/internals/how-synstate-solved-the-glitch/).
20
+ [^1]: See ["How SynState solved the glitch?"](https://noshiro-pf.github.io/mono/synstate/internals/how-synstate-solved-the-glitch/).
21
21
 
22
22
  ## Features
23
23
 
@@ -32,7 +32,7 @@
32
32
 
33
33
  ## Documentation
34
34
 
35
- - <https://noshiro-pf.github.io/synstate/>
35
+ - <https://noshiro-pf.github.io/mono/synstate/>
36
36
 
37
37
  ## Installation
38
38
 
@@ -111,7 +111,7 @@ const UserProfile = (): React.JSX.Element => {
111
111
  };
112
112
  ```
113
113
 
114
- This is equivalent to the following code without synstate-react-hook:
114
+ This is equivalent to the following code without synstate-react-hooks:
115
115
 
116
116
  ```tsx
117
117
  import * as React from 'react';
@@ -150,7 +150,7 @@ const UserProfile = (): React.JSX.Element => {
150
150
  };
151
151
  ```
152
152
 
153
- See also the [synstate-react-hooks README](../synstate-react-hooks/README.md).
153
+ See also the [synstate-react-hooks README](https://github.com/noshiro-pf/mono/tree/main/libs/synstate-react-hooks#readme).
154
154
 
155
155
  If you're using React v17 or earlier:
156
156
 
@@ -207,7 +207,7 @@ A state management library that scales from simple global state to complex async
207
207
 
208
208
  RxJS is the most well-known Observable library, and it excels at modeling asynchronous event processing. However, RxJS has a fundamental issue known as **glitch**[^1] — a phenomenon where derived values can temporarily enter inconsistent intermediate states during synchronous propagation. For a state management library, where consistency of derived state is critical, this is unacceptable. SynState was built from scratch with a glitch-free Observable implementation to solve this problem.
209
209
 
210
- For a detailed explanation, see ["How SynState solved the glitch?"](https://noshiro-pf.github.io/synstate/internals/how-synstate-solved-the-glitch/).
210
+ For a detailed explanation, see ["How SynState solved the glitch?"](https://noshiro-pf.github.io/mono/synstate/internals/how-synstate-solved-the-glitch/).
211
211
 
212
212
  ### Key Differences from RxJS
213
213
 
@@ -243,7 +243,7 @@ const [
243
243
  // type of state: InitializedObservable<number>
244
244
  // type of setState: (v: number) => number
245
245
  // type of updateState: (updater: (prev: number) => number) => number
246
- // type of resetState: () => void
246
+ // type of resetState: () => number
247
247
  // type of getSnapshot: () => number
248
248
  // type of initialState: number
249
249
 
@@ -1,12 +1,2 @@
1
- /**
2
- * Timer handle for Node.js / browser compatibility.
3
- *
4
- * Defined by what `clearTimeout` accepts rather than by what `setTimeout`
5
- * returns. The two are not the same type under the strict standard library:
6
- * `setTimeout` there returns `{} | null`, which `clearTimeout`'s
7
- * `number | undefined` parameter rejects. Every use of this type here is a
8
- * handle on its way to `clearTimeout` / `clearInterval`, so the consumer's
9
- * side is the one that has to fit.
10
- */
11
- export type TimerId = NonNullable<Parameters<typeof clearTimeout>[0]>;
1
+ export type TimerId = ReturnType<typeof setTimeout>;
12
2
  //# sourceMappingURL=timer.d.mts.map
@@ -1 +1 @@
1
- {"version":3,"file":"timer.d.mts","sourceRoot":"","sources":["../../../src/core/types/timer.mts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AACH,MAAM,MAAM,OAAO,GAAG,WAAW,CAAC,UAAU,CAAC,OAAO,YAAY,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC"}
1
+ {"version":3,"file":"timer.d.mts","sourceRoot":"","sources":["../../../src/core/types/timer.mts"],"names":[],"mappings":"AACA,MAAM,MAAM,OAAO,GAAG,UAAU,CAAC,OAAO,UAAU,CAAC,CAAC"}
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "synstate",
3
- "version": "3.0.3",
3
+ "version": "3.0.4",
4
4
  "description": "Type-safe State Management Library for TypeScript/JavaScript",
5
5
  "repository": {
6
6
  "type": "git",
@@ -51,8 +51,8 @@
51
51
  "prettier-plugin-packagejson": "3.0.2",
52
52
  "react": "19.2.8",
53
53
  "rxjs": "7.8.2",
54
- "synstate-react-hooks": "3.0.3",
55
- "synstate-react-hooks-compat": "3.0.3",
54
+ "synstate-react-hooks": "3.0.4",
55
+ "synstate-react-hooks-compat": "3.0.4",
56
56
  "ts-repo-utils": "10.6.2",
57
57
  "valtio": "2.3.2",
58
58
  "zustand": "5.0.15"
@@ -1,11 +1,2 @@
1
- /**
2
- * Timer handle for Node.js / browser compatibility.
3
- *
4
- * Defined by what `clearTimeout` accepts rather than by what `setTimeout`
5
- * returns. The two are not the same type under the strict standard library:
6
- * `setTimeout` there returns `{} | null`, which `clearTimeout`'s
7
- * `number | undefined` parameter rejects. Every use of this type here is a
8
- * handle on its way to `clearTimeout` / `clearInterval`, so the consumer's
9
- * side is the one that has to fit.
10
- */
11
- export type TimerId = NonNullable<Parameters<typeof clearTimeout>[0]>;
1
+ // Timer types for Node.js/Browser compatibility
2
+ export type TimerId = ReturnType<typeof setTimeout>;