Skip to content

Instantly share code, notes, and snippets.

@ai
Last active September 9, 2021 12:47
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ai/e8b0313b7733d54df15a4ce5499e087d to your computer and use it in GitHub Desktop.
Save ai/e8b0313b7733d54df15a4ce5499e087d to your computer and use it in GitHub Desktop.

New API for Nano Stores

We split all stores to 2 categories: store (for any store) and map (for key-value object and special helpers to work with keys).

Memory store is a regular store, which keep value in the memory (and do not clean it until page will be closed).

import { memoryStore } from 'nanostores'

let profileCache = memoryStore<Profile>(guestProfile)

Old API: store = createStore(); keepActive(store)

Daemon store is a store with constructor and destructor. It could listen other services (like WebSocket or History API). It has active and disabled mode. On first store’s listener it goes to active mode. On last listener unsubscibring it will be removed from the memory and will lost it’s value.

import { daemonStore } from 'nanostores'

let router = daemonStore<Route>(defaultRoute, () => {
  // subscribe to history API
  return () => {
    // unsubscribe from history API
  }
})
import { daemonMap } from 'nanostores'

// For key-value store

Old API: createStore()

Question: maybe “service store” is better than “deamon store”?

Deamon template is a template to create similar map stores. For instance, every User could be a separated store (useful for CRDT libraries like Logux, where every User store hides CRDT complixty inside):

import { deamonTemplate } from 'nanostores'

let User = deamonTemplate((store, id, ...args) => {
  // connect listsners to WebSocket log and listen for CRDT events
  () => {
    // remove listener from log
  }
})

let user1 = User(id, ...args)

Old API: defineMap()

@ai
Copy link
Author

ai commented Sep 7, 2021

Nice idea to use atom term instead of store for non-map stores https://github.com/dottostack/dotto.x

Also, compute is better than derived.

@AleksandrSl
Copy link

AleksandrSl commented Sep 7, 2021

IMO
Both daemon/service exist in the background, whether you use them now or not. In Angular, service usually exists outside of time and space and doesn't lose its value if components using it are gone.
Alas, I'm in the state of "You came here to criticize, but you don't even have your own variants". I will think harder

Compute(d) is more common than derived, though I came from Vue world full of them.
Atom seems pretty common too, in design systems at least. Though I don't personally like it, cause it conveys no meaning to me, why not composable for example, an atom has many properties, which of them do we wanna how in our stores?

@AleksandrSl
Copy link

BTW, maybe we can steal from Rx terminology, Observables can behave the same way if you unsubscribe from them they even abort actions, e.g. HTTP requests. The downside is that you can't change their state. Rx has Subject for this, but the name is awful.

@ai
Copy link
Author

ai commented Sep 8, 2021

Both daemon/service exist in the background

Good point :(

Atom seems pretty common too, in design systems at least. Though I don't personally like it, cause it conveys no meaning to me, why not composable for example, an atom has many properties, which of them do we wanna how in our stores?

Hm, I didn’t fully get the point. How “atom” is related to “composable”? Maybe you was confused that I talked about 2 different topics in that comment?

I am planning to use “atom” for stores with some simple variable like:

export const locale = atom('ru')

It has no relationship with compute and derived.

BTW, maybe we can steal from Rx terminology

It is not very common-used. Rx fans do not need Nano Stores, since they will prefer to continue using Rx.

@AleksandrSl
Copy link

About the compute I just agreed with your opinion that it is better than derived.

About atom I'm not sure, why is it better than store. Why atom? Because everything consists of atoms (that's why I talked about composable, this name tells you that these things could/should be composed into something bigger)? Or maybe because atom is the smallest particle (which is not now)?

Store has one meaning - it just holds some value.
Atom could mean many things, IMO, that's why I'm always confused with this term in technologies.

Hope, my thought are more clean now :)

@davidmz
Copy link

davidmz commented Sep 8, 2021

I think atom is a very good name for a non-map 'store' that holds one value without the internal structure, selectors and so on.

@davidmz
Copy link

davidmz commented Sep 8, 2021

Service/daemon sounds a bit puzzling to me. Maybe something like smartAtom / dynamicAtom would be better?

@AleksandrSl
Copy link

I think atom is a very good name for a non-map 'store' that holds one value without the internal structure, selectors and so on.

Still think that in this case singleValue('ru')/single('ru') is more precise and meaningful
Smart is no a good prefix because it doesn't describe the way in which a store is smart. In our case that it can be initialized and destroyed.

Silly idea: use mortal/immortal store, at least it shows that store could become deactivated/dead

@ai
Copy link
Author

ai commented Sep 9, 2021

I moved API discussion to issue nanostores/nanostores#57

@ai
Copy link
Author

ai commented Sep 9, 2021

Still think that in this case singleValue('ru')/single('ru') is more precise and meaningful

It can be an object (like we have in profile store or in router) which can be changed key by key.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment