npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@chasemoskal/snapstate

v0.0.9

Published

tiny robust state management

Downloads

46

Readme

🔮 snapstate

tiny robust state management

📦 npm install @chasemoskal/snapstate

👁️ watch for changes to properties
🕵️ track only the properties you are reading, automatically
♻️ keeps you safe from circular updates
⛹️ updates are debounced, avoiding duplicate updates
🌳 carve large state trees into substates
🧬 implemented with recursive es proxies
🔬 typescript-native types, es modules
💖 free and open source, just for you

snapstate is designed to be a modern replacement for mobx. mobx was amazing, but has grown comically large at like 50 KB. mobx is also global, among other complications that we don't prefer.

snapstate is 1.5 KB, minified and gzipped.

🕵️ tracking changes to properties

  • first, let's create some state.
    import {snapstate} from "@chasemoskal/snapstate"
    
    const snap = snapstate({
      count: 0,
      coolmode: "enabled",
      also: {
        nesting: {
          isAllowed: true,
        },
      },
    })
  • snap.track allows us to track changes to the state
    snap.track(state => {
      console.log(state.count)
       //               ☝️
       // snapstate detects this property read,
       // and will run our track callback
       // whenever this property changes
    })
     // 0 —— runs once initially
    
    snap.state.count += 1
     // 1 —— automatically runs the relevant tracker functions
    
    snap.state.coolmode = "super"
     // *nothing happens*
     // our track callback doesn't care about this property :)
  • if you prefer driving stick-shift, we can make a manual track and even avoid the initial run.
    snap.track(
    
      // observer: listen specifically to "count"
      ({count}) => ({count}),
    
      // reaction: responding to changes
      ({count}) => console.log(`count changed: ${count}`),
    )
    
    snap.state.count += 1
     // 1
  • of course, we can stop tracking things when we want.
    const untrack = snap.track(({count}) => console.log(count))
     // 0
    
    snap.state.count += 1
     // 1
    
    untrack()
    snap.state.count += 1
     // *nothing happens*

💾 control which parts of your app can write to state

this is a pillar of good state management.

if every part of our app can write to the state, all willy-nilly, it quickly becomes a convoluted mess that is hard to debug.

  • snap.readable is just like snap.state, except that it's read-only.
    const snap = snapstate({count: 0})
    
    snap.state.count += 1
     // this is allowed
    
    snap.readable.count += 1
     // SnapstateReadonlyError —— no way, bucko!
  • we can pass the readable around to the parts of our application that should only have read-access to the state (like our components).
  • but components will also need access to track, subscribe, and the rest of it —
  • so snapstate has a handy restricted function, which makes a read-only version of a snapstate.
    import {snapstate, restricted} from "@chasemoskal/snapstate"
    const snap = snapstate({count: 0})
    
    myFrontendComponents({
      snap: restricted(snap),
    })
  • it's easy to formalize actions with snapstate.
    const snap = snapstate({count: 0})
    
    // only our actions have write-access to state
    const actions = {
      increment() {
        snap.state.count += 1
      },
    }
    
    myFrontendComponents({
    
      // components only have read-only access to the state
      snap: restricted(snap),
    
      // components can call our formalized actions to change the state
      actions,
    })
  • note: snap.state and snap.writable are aliases for each other.

👁️ subscribe to any change in the whole state tree

  • subscriptions will execute whenever any state is changed in the tree.
    snap.subscribe(state => {
      console.log("something has changed")
    })
  • of course you can unsubscribe, too.
    const unsubscribe = snap.subscribe(state => {
      console.log("something has changed")
    })
    
    unsubscribe()

✋ untrack and unsubscribe all

  • delete all trackers
    snap.untrackAll()
  • delete all subscriptions
    snap.unsubscribeAll()

⛹️ debouncing and waiting

  • tracking and subscription callbacks are debounced.
    this prevents consecutive changes from firing more callbacks than necessary.
    const snap = snapstate({count: 0})
    snap.track(({count}) => console.log(count))
    snap.state.count += 1
    snap.state.count += 1
    snap.state.count += 1
     // 1 —— only runs once
  • but be advised — this might mean you have to wait before seeing the effects of your callbacks
    const snap = snapstate({count: 0})
    
    let called = false
    snap.subscribe(() => called = true)
    
    snap.state.count += 1
    console.log(called)
     // false —— *what the heck!?*
    
    await snap.wait()
     // true —— oh! i just had to wait, for the debouncer!

♻️ circular-safety

  • you are prevented from writing to state while reacting to it.
    const snap = snapstate({count: 0})
    
    snap.track(state => {
      state.count += 1
       // SnapstateReadonlyError —— not a chance, buster!
    
       // "state" is actually "snap.readable" in this context,
       // (same with subscribe)
    })
  • you might think you're clever, and could outsmart snapstate. you'd be wrong!
    snap.track(({count}) => {
      // here's you being clever, thinking you can access the *outer* snap.state
      snap.state.count += 1
       // SnapstateCircularError —— dead in your tracks!
    })
  • as we've established, you can't make circular references in track callbacks.
  • you also can't make circles with track reactions.
    snap.track(
      ({count}) => ({count}),
      () => {
        snap.state.count += 1
      },
    )
    snap.state.count += 1
    await snap.wait()
     // SnapstateCircularError —— thwarted again, buddy!
  • and you can't make circles in subscriptions, either.
    snap.subscribe(() => snap.state.count += 1)
    snap.state.count += 1
    await snap.wait()
     // SnapstateCircularError —— just give up
  • you can catch these async errors on the snap.wait() promise.

✂️ substate: carve your state into subsections

  • it's awkward to pass your whole application state to every little part of your app.
  • so you can snip off chunks, to pass along to the components that need it.
    import {snapstate, substate} from "@chasemoskal/snapstate"
    
    const snap = snapstate({
      outerCount: 1,
      coolgroup: {
        innerCount: 2,
      }
    })
    
    const coolgroup = substate(snap, tree => tree.coolgroup)
    
    // note: coolgroup has no access to "outerCount"
    console.log(coolgroup.state.innerCount)
     // 2
    
    coolgroup.track(state => console.log(state.innerCount))
    coolgroup.state.innerCount += 1
    await coolgroup.wait()
     // 3
  • a substate's subscribe function only listens to its subsection of the state.
  • a substate's untrackAll function only applies to tracking called on the subsection.
  • a substate's unsubscribeAll function only applies to subscriptions called on the subsection.
  • substates can also be restricted.
    const restrictedCoolgroup = restricted(coolgroup)
    restrictedCoolgroup.state.innerCount += 1
     // SnapstateReadonlyError

👨‍⚖️ super-strict typescript readonly

  • introducing snap.readonly. it's snap.readable's strict and demanding mother-in-law.
  • readonly literally is readable, but with more strict typescript typing.
  • you see, typescript is extremely strict about its typescript "readonly" properties.
    so much so, that it's very painful to use typescript "readonly" structures throughout your app.
  • for this reason, snapstate provides snap.readable by default, which will throw errors only at runtime when you're being naughty attempting to write properties there — but the typescript compiler doesn't complain with readable.
  • if your shirt is fully tucked-in, you can use snap.readonly to produce compile-time typescript errors.
  • anywhere you find a readable (for example in track and subscribe callbacks), you could set its type to Read<typeof readable> to make typescript super strict about it.

📜 beware of arrays, maps, and other fancy objects

  • snapstate only tracks changes when properties are set on plain objects.
  • what this means, is that methods like array.push aren't visible to snapstate.
    const snap = snapstate({myArray: []})
    
    // bad -- updates will not respond.
    snap.state.myArray.push("hello")
  • to update an array, we must wholly replace it:
    // good -- updates will respond.
    snap.state.myArray = [...snap.state.myArray, "hello"]
  • this also means that the properties on any class instances won't be tracked.
    const snap = snapstate({
      date: new Date(), // properties within this aren't tracked
      myCoolObject: new MyCoolObject(), // properties within this aren't tracked
    })
  • this is an entirely survivable state of affairs, but we may eventually do the work to implement special handling for arrays, maps, sets, and other common objects. (contributions welcome!)

🧬 using proxies in your state, if you must

  • snapstate doesn't like proxies in the state, so it destroys them on-sight (by making object copies).
  • this is to prevent circularity issues, since snapstate's readables are made of proxies.
  • if you'd like to specifically allow a particular proxy, you can convince snapstate to allow it into the state tree, by having your proxy return true when symbolToAllowProxyIntoState is accessed.
  • snapstate will check for this symbol whenever it ingests objects into the state.
  • here's an example:
    import {snapstate, symbolToAllowProxyIntoState} from "@chasemoskal/snapstate"
    
    const snap = snapstate({
      proxy: new Proxy({}, {
        get(t, property) {
          if (property === symbolToAllowProxyIntoState)
            return true
          else if (property === "hello")
            return "world!"
        },
      })
    })
    
    console.log(snap.state.proxy.hello)
     // "world!"

💖 made with open source love

mit licensed.

please consider contributing by opening issues or pull requests.

  // chase