@e280/strata 0.0.0 → 0.0.1

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.
Files changed (2) hide show
  1. package/README.md +9 -10
  2. package/package.json +1 -1
package/README.md CHANGED
@@ -9,6 +9,7 @@
9
9
  📦 `npm install @e280/strata`
10
10
  🧙‍♂️ probably my tenth state management library, lol
11
11
  💁 it's all about rerendering ui when data changes
12
+ 🦝 used by our view library [@e280/sly](https://github.com/e280/sly)
12
13
  🧑‍💻 a project by https://e280.org/
13
14
 
14
15
  🚦 **signals** — ephemeral view-level state
@@ -17,12 +18,6 @@
17
18
 
18
19
  <br/>
19
20
 
20
- > [!TIP]
21
- > incredibly, signals and trees are interoperable.
22
- > that means, effects and computeds are responsive to changes in tree state.
23
-
24
- <br/>
25
-
26
21
  ## 🚦 strata signals
27
22
  > *ephemeral view-level state*
28
23
 
@@ -54,7 +49,7 @@ import {signal, effect, computed} from "@e280/strata"
54
49
  count() // get
55
50
  await count(2) // set
56
51
  ```
57
- > to achieve this hipster syntax i had to make the implementation so damn cursed, lol 💀
52
+ > *you'd better appreciate this damn hipster syntax, because it makes the implementation cursed, lol* 💀
58
53
  - **signal get/set syntax**
59
54
  ```ts
60
55
  count.get() // get
@@ -242,20 +237,24 @@ import {Trunk} from "@e280/strata"
242
237
 
243
238
  <br/>
244
239
 
245
- ## 🪄 tracker — integrations
240
+ ## 🪄 strata tracker
246
241
  > *reactivity integration hub*
247
242
 
248
243
  ```ts
249
244
  import {tracker} from "@e280/strata/tracker"
250
245
  ```
251
246
 
252
- the *items* that the tracker tracks can be any object, or symbol.. the tracker cares about the identity of the item, not the value (tracker holds them in a WeakMap to avoid creating a memory leak)..
247
+ if you're some kinda framework author, making a new ui thing, or a new state concept -- then you can use the `tracker` to jack into the strata reactivity system, and suddenly your stuff will be fully strata-compatible, reactin' and triggerin' with the best of 'em.
248
+
249
+ the tracker is agnostic and independent, and doesn't know about strata specifics like signals or trees -- and it would be perfectly reasonable for you to use strata solely to integrate with the tracker, thus making your stuff reactivity-compatible with other libraries that use the tracker, like [sly](https://github.com/e280/sly).
250
+
251
+ note, the *items* that the tracker tracks can be any object, or symbol.. the tracker cares about the identity of the item, not the value (tracker holds them in a WeakMap to avoid creating a memory leak)..
253
252
 
254
253
  ### 🪄 integrate your ui's reactivity
255
254
  - we need to imagine you have some prerequisites
256
255
  - `myRenderFn` -- your fn that might access some state stuff
257
256
  - `myRerenderFn` -- your fn that is called when some state stuff changes
258
- - it's OK if these are the same fn, but they don't have to be
257
+ - it's okay if these are the same fn, but they don't have to be
259
258
  - `tracker.observe` to check what is touched by a fn
260
259
  ```ts
261
260
  // 🪄 run myRenderFn and collect seen items
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@e280/strata",
3
- "version": "0.0.0",
3
+ "version": "0.0.1",
4
4
  "description": "state management",
5
5
  "license": "MIT",
6
6
  "author": "Chase Moskal <chasemoskal@gmail.com>",