Forem: Victor Didenko

effector-storage v6

Victor Didenko — Mon, 08 May 2023 12:25:35 +0000

Wow, that was a long jump! But now effector-storage version 6 is landed.

So, whats new?

Contracts support

This could be a minuscule change for a majority of this library users, but I consider this like a big step toward serious business. "Contract" sounds serious, doesn't it?

Like any source, which your code has no full control on, localStorage values should never be trusted and needs to be validated. Any script kiddie can open DevTools and change localStorage value, thus breaking your big-money application. In order to prevent it, data should be validated in two levels — structurally and businessly. effector-storage library cannot help you with your business logic, but at least, it can validate values against contracts now.

In a simple case, contract could be just a simple type guard:

persist({
  store: $counter,
  key: 'counter',
  contract: (raw): raw is number => typeof raw === 'number',
  fail: failed
})

So, if localStorage somehow will contain a string now — persist will fail restoring store $counter, and trigger failed event with operation: "validate".

Note though, that contracts are working after parsing (deserializing), so if localStorage value is not a valid JSON string at all — persist will fail, triggering failed event with operation: "get".

In more complex cases, when you need to validate data against some complex structure with complex rules — effector-storage fully supports Farfetched contracts, so you can use any adapter from Farfetched — runtypes, zod, io-ts, superstruct, typed-contracts:

import { Record, Literal, Number } from 'runtypes'
import { runtypeContract } from '@farfetched/runtypes'

const Asteroid = Record({
  type: Literal('asteroid'),
  mass: Number,
})

persist({
  store: $asteroid,
  key: 'asteroid',
  contract: runtypeContract(Asteroid),
  fail: failed
})

There are two gotchas with contracts:

From effector-storage point of view it is absolutely normal, when there is no persisted value in the storage yet. So, undefined value is always valid, even if contract does not explicitly allow it.
effector-storage does not prevent persisting invalid data to the storage, but it will validate it nonetheless, after persisting, so, if you write invalid data to the storage, fail will be triggered, but data will be persisted.

Exported adapters

Sometimes it is required to persist different stores within different storages within the same module. And to avoid names clashes in version 5 you have to write something like this:

import { persist as localPersist } from 'effector-storage/local'
import { persist as queryPersist } from 'effector-storage/query'

localPersist({ store: $session })
queryPersist({ store: $page })

In version 6 all adapters now are exported alongside with persist function, and could be used on their own. More over, all (major) adapters are exported from the root package as well, so you can use them all in once with a single import statement:

import { persist, local, query } from 'effector-storage'

persist({ adapter: local, store: $session })
persist({ adapter: query, store: $page })

Strictly speaking, imported local and query in the example above are not adapters, but adapter factories. So you can call factory to create an adapter instance, if you need some adapter adjustments:

persist({
  store: $date,
  adapter: local({
    serialize: (date) => String(date.getTime()),
    deserialize: (timestamp) => new Date(Number(timestamp)),
  }),
})

Or you can pass any adapter factory arguments right into persist!

persist({
  store: $date,
  adapter: local,
  serialize: (date) => String(date.getTime()),
  deserialize: (timestamp) => new Date(Number(timestamp)),
})

Adapter utilities

With exported adapters new idea has crossed my mind: what if you could write a high order function, which will accept adapter (or adapter factory), and slightly change it behaviour?

So, I made a few:

`async` utility function

It takes any synchronous storage adapter (or factory) and makes it asynchronous:

persist({
  adapter: async(local),
  store: $counter,
  done: doneEvent,
})

This could be useful, when you need to postpone store restoring a bit. If you don't use pickup option, persist begins restoring store state right at the moment. So, in case of synchronous localStorage, right after persist is executed — store value already be restored from the storage (of course, if it was persisted beforehand). Sometimes it can affect your business logic, for example, if you need to react on store restoring, you need to take that behaviour into account, and define all connections (like samples) before you call persist.

async utility function can help you with that, freeing you from that burden of keeping declarations order in mind.

`either` utility function

It takes two adapters (or factories), and returns first of them, which is not "no-op".

What the heck is "no-op" adapter?

Version 6 introduces two separate "terms", or "states" for adapters:

Supported — this means, that storage is supported by environment, for example, localStorage is supported in browsers, but not supported in Nodejs.
Available — this means, that storage is supported and available, for example, localStorage could be forbidden by browser security policies.

So, if adapter is doing nothing (like nil adapter), or it is not supported — this is "no-op" adapter.

persist({
  store: $store,
  adapter: either(local, log),
  key: 'store'
})

In the example above store $store will be persisted in localStorage in the browser, and will use new log adapter, which just prints operations, in Nodejs.

Breaking change❗️ In version 5 local adapter was behaving like not supported (and did nothing) when localStorage is forbidden by browser security policies. In version 6 this considered like not available, thus, local adapter will trigger security error on each operation. You can handle this and ask user to enable localStorage, for example.

`farcached` utility function

It takes any cache adapter from Farfetched and converts it to be used as persist adapter :)

This one I made mostly out of fun and to show possibilities, which opens with utility functions approach.

From real usage point of view, using Farfetched cache adapters could be useful, when you need logic for cache invalidation, because all of its adapters have maxAge option out of the box.

Also, you could use Farfetched cache adapters to inject different cache adapters with fork using cache.__.$instance internal store.

import { localStorageCache } from '@farfetched/core'

persist({
  store: $counter3,
  adapter: farcached(localStorageCache({ maxAge: '15m' })),
})

Adapter context

This is an experimental feature, and I think it will be like dark horse for a while 🤫 But I plan to show it fully in next minor releases.

In a few words, context is aimed for two main purposes:

Asynchronous updates from storage in scope
Using different environments in adapter

You can pass context in two ways:

As pickup event payload
As new context event payload

persist will remember scope, in which you have called pickup or context, and will use this scope for any asynchronous updates from storage (like on "storage" event).

Also, context will be passed as a second argument in adapter's get and set functions, and adapter can use it as it pleases.

Force sync mode

Due to minor performance optimizations, when local adapter receives "storage" event — it takes new storage value from this event's payload. Obviously, there is no need to read (relatively slow) localStorage when new value is right here, inside the already received event.

But in some cases this approach could lead to stores desynchronization with simultaneous or almost simultaneous updates from different tabs. You can call this race condition.

This happens because "storage" event is happening only when storage is modified from another tab/window. So, in any situation with simultaneous or almost simultaneous localStorage updates from more than one tab — there always will be a loser tab, which will become unsynchronized. I've drawn an image with two tabs: each tab receives update from another tab, and one of the tabs inevitably become unsynchronized with localStorage:

I consider this very rare case, so, version 6 does not change default behaviour (with using new value from event), but adds new possible value for sync option instead — 'force':

persist({
  store: $balance,
  key: 'balance',
  sync: 'force'
})

This will ignore new value from "storage" event, and will forcibly read new value from localStorage instead, thus eliminating desynchronization issue.

Throttle/batch writes

Version 6 adds new option timeout for three adapters: local, session and query. It behaves slightly differently for them, but meaning is plain — postpone writes to a storage.

For local and session (and base storage) adapters timeout option behaves like throttle for the single persist (without leading write). So, if you have store, which updates frequently and persisted in the localStorage, you can slightly improve performance by throttling access to the localStorage with this option.

For query adapter timeout option behaves like throttle (without leading write) and batch. So, if you have many stores, which are persisted in a query string, you can use this option to throttle and batch the query string updates.

Drop Effector v21 support

Version 5 fully supports Effector v21, which was out on July 6, 2020 — almost three years ago. This is possible, because effector-storage uses only base Effector's functionality, and because Effector has an excellent backward compatibility.

But times go on, and Effector v22 has been out on August 31, 2021 — almost two years ago. effector-storage already has some small tweaks to support different versions and new features, so, I think, it is time to stop supporting version 21.

Also, Nodejs v14 has reached end-of-life on April 30, 2023 — so, version 6 also drops it. And so should you ;)

That is all I got for you today, stay tuned ;)

E~wee~ctor: writing tiny Effector from scratch #4 — Effect

Victor Didenko — Fri, 10 Apr 2020 18:12:36 +0000

Hey, all!

Upon this moment we've implemented two main Effector's entities – an event and a store – and were avoiding an effect. So, let's accept this challenge!

First of all, according to documentation, an effect is a container for async function. It is used for side-effects, like interaction with a server, or any timeouts and intervals. Actually, you can use any function inside an effect, it doesn't need to be asynchronous in general, but it is so in most cases. But it is important in the Effector ecosystem to use effects for side-effects.

An effect is a complex entity, and contains of a dozen nodes and other entities:

done – is an event triggered when handler is resolved
fail – is an event triggered when handler is rejected or throws error
finally – is an event triggered when handler is resolved, rejected or throws error
doneData – is an event triggered with result of effect execution
failData – is an event triggered with error thrown by effect
pending – is a boolean store containing a true value until the effect is resolved or rejected
inFlight – is a store showing how many effect calls aren't settled yet

Here is what we will start with:

export const createEffect = ({ handler }) => {
  const effect = payload => launch(effect, payload)
  effect.graphite = createNode()
  effect.watch = watch(effect)

  effect.prepend = fn => {
    const prepended = createEvent()
    createNode({
      from: prepended,
      seq: [compute(fn)],
      to: effect,
    })
    return prepended
  }

  // TODO

  effect.kind = 'effect'
  return effect
}

This stub looks exactly like part of an event. In fact, Effector uses an event under the hood as a base for an effect, but we will create it from scratch for simplicity.

The only differences from an event here yet is that createEffect function accepts an object with the handler field. And effect.kind is "effect", so we can distinguish effects from other entities.

Now let's add a method use to change handler:

  effect.use = fn => (handler = fn)
  effect.use.getCurrent = () => handler

And create bunch of child events for the effect:

  const anyway = createEvent()
  const done = anyway.filterMap(({ status, ...rest }) => {
    if (status === 'done') return rest
  })
  const fail = anyway.filterMap(({ status, ...rest }) => {
    if (status === 'fail') return rest
  })
  const doneData = done.map(({ result }) => result)
  const failData = fail.map(({ error }) => error)

  effect.finally = anyway
  effect.done = done
  effect.fail = fail
  effect.doneData = doneData
  effect.failData = failData

Hereby we've created all the events for our effect. Base event is effect.finally (finally is a reserved word, so we can't name a variable like this, so we use name anyway for it). All other events are derived from this base event:

Looking at the code above I feel urgent desire to extract common logic to helper functions:

const status = name => ({ status, ...rest }) =>
  status === name ? rest : undefined

const field = name => object => object[name]

// --8<--

  const anyway = createEvent()
  const done = anyway.filterMap(status('done'))
  const fail = anyway.filterMap(status('fail'))
  const doneData = done.map(field('result'))
  const failData = fail.map(field('error'))

Now let's add stores pending and inFlight:

  effect.inFlight = createStore(0)
    .on(effect, x => x + 1)
    .on(anyway, x => x - 1)
  effect.pending = effect.inFlight.map(amount => amount > 0)

That is simple: store inFlight subscribes to the effect itself and its finally event. And boolean store pending is true when inFlight has positive value.

And now we've come close to the main part of the effect – running our side-effect function handler. We will just add a single step to our main effect's node, where the handler will be launched:

  effect.graphite.seq.push(
    compute(params => {
      try {
        const promise = handler(params)
        if (promise instanceof Promise) {
          promise
            .then(result => launch(anyway, { status: 'done', params, result }))
            .catch(error => launch(anyway, { status: 'fail', params, error }))
        } else {
          launch(anyway, { status: 'done', params, result: promise })
        }
      } catch (error) {
        launch(anyway, { status: 'fail', params, error })
      }
      return params
    })
  )

we run the handler inside try-catch block, so if we get a synchronous exception – it will be caught
if handler returns a Promise, we wait for it to settle
if handler returns not a Promise, we just use returned value as a result
in any case we launch result (either successful or failed) to the finally event, so it will be processed to the done/fail/doneData/failData events automatically

Here is one important thing left though, without which this code will not work properly:

Steps are executed during the computation cycle inside the kernel
We use function launch inside the step, while we are inside the computation cycle
Function launch starts the computation cycle

Do you see the problem?

We have one single queue to process, and secondary run of the computation cycle inside the already running computation cycle will mess it all around! We don't want this, so let's add a guard to protect from this situation in our kernel:

let running = false
const exec = () => {
  if (running) return
  running = true

  // --8<--

  running = false
}

After this fix step inside effect's node will work perfectly.

But there is one more thing to fix: effect should return a Promise, so it can be awaited. For now our effect's function, which is tied to the node, is exactly the same as function for an event – it just launches given payload to the node (and returns nothing):

  const effect = payload => launch(effect, payload)

But it should return a Promise, as was said. And we should be able to somehow resolve or reject this Promise from inside step.

And here we need so called Deferred object. This is a common pattern to have a Promise, which can be settled from outside. Here is a nice explanation of this approach, read this, if you didn't meet deferred objects yet.

A Promise represents a value that is not yet known.
A Deferred represents work that is not yet finished.

export const defer = () => {
  const deferred = {}

  deferred.promise = new Promise((resolve, reject) => {
    deferred.resolve = resolve
    deferred.reject = reject
  })

  // we need this to avoid 'unhandled exception' warning
  deferred.promise.catch(() => {})

  return deferred
}

defer function creates a deferred object. Now we can use this deferred object to return a Promise from an effect, and settle it from inside a step. But we also need to consider a situation, when the effect is called not directly, but from the other graph node, for example like forward({ from: event, to: effect }). In that case we don't need to create useless Deferred object.

Let's use helper class to distinguish direct and indirect call cases. We could use simple object, but we can't be sure, that one day effect will not receive exactly this shape of an object as a payload. So we use internal class and instanceof check, to be sure, that only our code can create class instance.

⚠️ Effector checks this differently, using call stack, provided by the kernel, but we will go simple way :)

function Payload(params, resolve, reject) {
  this.params = params
  this.resolve = resolve
  this.reject = reject
}

Now we need to change main function, and then add one more step to check use case:

  const effect = payload => {
    const deferred = defer()
    launch(effect, new Payload(payload, deferred.resolve, deferred.reject))
    return deferred.promise
  }

  // --8<--

    compute(data =>
      data instanceof Payload
        ? data // we get this data directly
        : new Payload( // we get this data indirectly through graph
            data,
            () => {}, // dumb resolve function
            () => {} // dumb reject function
          )
    )

After this step next one will get a Payload instance in both cases, either effect was called directly or indirectly. We need to change our existing step to handle this new Payload instance instead of plain params.

// helper function to handle successful case
const onDone = (event, params, resolve) => result => {
  launch(event, { status: 'done', params, result })
  resolve(result)
}

// helper function to handle failed case
const onFail = (event, params, reject) => error => {
  launch(event, { status: 'fail', params, error })
  reject(error)
}

// --8<--

    compute(({ params, resolve, reject }) => {
      const handleDone = onDone(anyway, params, resolve)
      const handleFail = onFail(anyway, params, reject)
      try {
        const promise = handler(params)
        if (promise instanceof Promise) {
          promise.then(handleDone).catch(handleFail)
        } else {
          handleDone(promise)
        }
      } catch (error) {
        handleFail(error)
      }
      return params
    })

And that's it, our effect shines and ready!

I am slightly worried, that reading this chapter could be difficult, and someone could not glue code pieces together. As always, you can find whole changes in this commit, so feel free to check it out!

Thank you for reading!
To be continued...

E~wee~ctor: writing tiny Effector from scratch #3 — Simple API methods

Victor Didenko — Sat, 04 Apr 2020 09:46:01 +0000

Hi, folks!

In this article I want to implement some simple Effector API functions. But before we start, let's improve one thing.

You might have noticed, that we create auxiliary node and add it to the next array of other node quite often, like this:

  event.map = fn => {
    const mapped = createEvent()

    // create new node
    const node = createNode({
      next: [mapped.graphite],
      seq: [compute(fn)],
    })

    // add it to the event's next nodes
    event.graphite.next.push(node)

    return mapped
  }

Let's improve createNode function, so it will do it for us:

export const getGraph = unit => unit.graphite || unit

const arrify = units =>
  [units]
    .flat()          // flatten array
    .filter(Boolean) // filter out undefined values
    .map(getGraph)   // get graph nodes

export const createNode = ({ from, seq = [], to } = {}) => {
  const node = {
    next: arrify(to),
    seq,
  }
  arrify(from).forEach(n => n.next.push(node))
  return node
}

I've renamed parameter next to to, and added new parameter from, accepting previous nodes.
getGraph helper function gives us ability to pass both units and nodes, without taking care of field .graphite. Also, with arrify helper function we can pass single unit or array of units to the from and to parameters.

Now any createNode call should be more readable:

from node → sequence of steps → to node

With this change we can rewrite example above as following:

  event.map = fn => {
    const mapped = createEvent()

    // create new node
    // and automatically add it to the event's next nodes
    createNode({
      from: event,
      seq: [compute(fn)],
      to: mapped,
    })

    return mapped
  }

I wont show you all diffs of all createNode function occurrences, the changes are trivial, you can make them yourself, or check commit by the link in the end of the article, as usual :)

Let's move on to the API methods!

forward

export const forward = ({ from, to }) => {
  createNode({
    from,
    to,
  })
}

That's simple :)

⚠️ Well, not quite so, Effector's Forward returns so called Subscription, to be able to remove connection. We will implement subscriptions in later chapters.

Remember we can pass array of units/nodes to createNode function, so forward can handle arrays automatically!

merge

export const merge = (...events) => {
  const event = createEvent()
  forward({
    from: events.flat(), // to support both arrays and rest parameters
    to: event,
  })
  return event
}

merge creates new event and forwards all given events to that new one.

⚠️ Effector's merge supports only arrays. I've added rest parameters support just because I can ^_^

split

const not = fn => value => !fn(value) // inverts comparator function

export const split = (event, cases) => {
  const result = {}

  for (const key in cases) {
    const fn = cases[key]
    result[key] = event.filter(fn)
    event = event.filter(not(fn))
  }

  result.__ = event
  return result
}

split function splits event into several events, which fire if source event matches corresponding comparator function.

"It may seem difficult at first, but everything is difficult at first."
— Miyamoto Musashi

So, take your time understanding this function.
And here is diagram of split:

Or in a less detailed, but more beautiful form of a tree, split is actually looks like a recursive binary splitting:

createApi

export const createApi = (store, setters) => {
  const result = {}

  for (const key in setters) {
    const fn = setters[key]
    result[key] = createEvent()
    store.on(result[key], fn)
  }

  return result
}

createApi function is just a simple factory for events, and it auto-subscribes given store on each one of them.

is

We can distinguish events and stores by doing typeof (events are functions and stores are plain objects). But this approach has a flaw – when we will implement effects it will fail, because effects are functions too. We could go further and check all properties – this is called duck typing. But Effector does that very simple – each unit has a special field kind:

export const createEvent = () => {
  // --8<--
+  event.kind = 'event'
  return event
}

export const createStore = defaultState => {
  // --8<--
+  store.kind = 'store'
  return store
}

And with this field kind we can easily check our units:

const is = type => any =>
  (any !== null) &&
  (typeof any === 'function' || typeof any === 'object') &&
  ('kind' in any) &&
  (type === undefined || any.kind === type)

export const unit = is()
export const event = is('event')
export const store = is('store')

restore

restore behaves differently on different inputs, so we will need our brand new is functionality:

export const restore = (unit, defaultState) => {
  if (is.store(unit)) {
    return unit
  }

  if (is.event(unit)) {
    return createStore(defaultState).on(unit, (_, x) => x)
  }

  const result = {}
  for (const key in unit) {
    result[key] = createStore(unit[key])
  }
  return result
}

restore function can also handle effects, but we don't have them yet.

Other API functions, like sample, guard and combine, we will describe in later chapters.

And as always, you can find all this chapter changes in this commit.

Thank you for reading!
To be continued...

E~wee~ctor: writing tiny Effector from scratch #2 — Maps and Filters

Victor Didenko — Thu, 02 Apr 2020 19:07:29 +0000

Hi, all!

In the previous article we've made minimal implementation of our new E~wee~ctor library, which could run "counter" example from Effector website. But, honestly, this example is all it could do, nothing more. So, let's add some more features.

In this chapter I want to add maps and filters.

Steps

Last time we decided to use functions as steps. That was good and simple for the start, but unfortunately we can't go further with this approach. In some cases kernel needs to make different decisions depending on steps. Like filter functionality – in case filter function returns false, kernel should stop execution for the current graph branch.

So we need to introduce step types:

const step = type => fn => ({
  type,
  fn,
})

export const compute = step('compute')

Function step creates step object, containing fields type and fn. Let's begin with single step compute and change our existing code.

// change `watch` node

export const watch = unit => fn => {
  const node = createNode({
-    seq: [fn],
+    seq: [compute(fn)],
  })
  unit.graphite.next.push(node)
}

// --8<--

// change `store` unit

  store.graphite = createNode({
-    seq: [value => (currentState = value)],
+    seq: [compute(value => (currentState = value))],
  })

  store.on = (event, fn) => {
    const node = createNode({
      next: [store.graphite],
-      seq: [value => fn(currentState, value)],
+      seq: [compute(value => fn(currentState, value))],
    })
    event.graphite.next.push(node)
    return store
  }

We also need to change kernel with following requirements:

Kernel should be able to do different actions depending on a step type
For the filter functionality we should be able to stop execution of current branch

In the first version we've used .forEach to traverse through all node steps. But it is impossible to stop and quit .forEach, so we have to rewrite it with good old for cycle:

const exec = () => {
  while (queue.length) {
    let { node, value } = queue.shift()

    for (let i = 0; i < node.seq.length; i++) {
      const step = node.seq[i]
      switch (step.type) {
        case 'compute':
          value = step.fn(value)
          break
      }
    }

    node.next.forEach(node => queue.push({ node, value }))
  }
}

Now our steps preparations are done, let's go with maps first.

Event.map

export const createEvent = () => {
  // --8<--

  event.map = fn => {
    const mapped = createEvent()
    const node = createNode({
      next: [mapped.graphite],
      seq: [compute(fn)],
    })
    event.graphite.next.push(node)
    return mapped
  }

  // --8<--
}

.map method accepts map function. It creates new event unit, and ties two events, old and new one, with new auxiliary node map. And given map function is executed inside this auxiliary node, to modify data.

Event.prepend

Prepend is kind of like reverse map – it prepends event with new event.

export const createEvent = () => {
  // --8<--

  event.prepend = fn => {
    const prepended = createEvent()
    const node = createNode({
      next: [event.graphite],
      seq: [compute(fn)],
    })
    prepended.graphite.next.push(node)
    return prepended
  }

  // --8<--
}

.prepend method behaves almost exactly like .map, just in an opposite direction:

Store.map

export const createStore = defaultState => {
  // --8<--

  store.map = fn => {
    const mapped = createStore(fn(currentState))
    const node = createNode({
      next: [mapped.graphite],
      seq: [compute(fn)],
    })
    store.graphite.next.push(node)
    return mapped
  }

  // --8<--
}

.map method accepts map function. It creates new store unit, and ties two stores, old and new one, with new auxiliary node map. And given map function is executed inside this auxiliary node, to modify data.
Additionally, to compute new store initial state, this method calls map function once with current store state.

⚠️ It should be noted, that this implementation doesn't follow Effector API completely – map function doesn't receive mapped store state as a second argument. We will fix this in later chapters.

Event.filter

Filter functionality is a bit different beast. This is the first place, where we need new step type:

export const filter = step('filter')

We also need to teach our kernel to support this new step filter:

const exec = () => {
-  while (queue.length) {
+  cycle: while (queue.length) {
    let { node, value } = queue.shift()

    for (let i = 0; i < node.seq.length; i++) {
      const step = node.seq[i]
      switch (step.type) {
        case 'compute':
          value = step.fn(value)
          break
+        case 'filter':
+          if (!step.fn(value)) continue cycle
+          break
      }
    }

    node.next.forEach(node => queue.push({ node, value }))
  }
}

If we meet a step with type filter, and its filter function returns falsy value – we just skip all other execution in this branch.
If you are unfamiliar with this strange syntax continue cycle – this is called label, you can read about it here.

Next let's add .filter method to event:

export const createEvent = () => {
  // --8<--

  event.filter = fn => {
    const filtered = createEvent()
    const node = createNode({
      next: [filtered.graphite],
      seq: [filter(fn)],
    })
    event.graphite.next.push(node)
    return filtered
  }

  // --8<--
}

As you can see, it looks exactly like .map method, with only difference – instead of step compute we use step filter.

⚠️ This implementation doesn't follow Effector API also – due to historical reasons Effector's Event.filter accepts not function, but object {fn}.

Event.filterMap

export const createEvent = () => {
  // --8<--

  event.filterMap = fn => {
    const filtered = createEvent()
    const node = createNode({
      next: [filtered.graphite],
      seq: [compute(fn), filter(value => value !== undefined)],
    })
    event.graphite.next.push(node)
    return filtered
  }

  // --8<--
}

.filterMap method is like .map and .filter combined together. This is the first place, where we've created auxiliary node filterMap, containing two steps – compute, to execute given function, and filter, to check, if we have undefined or not value.

And that's it for today!
You can see all this chapter changes in this commit.
I've also added automated testing, so we can be sure, that we will not break old functionality with new one.

Thank you for reading!
To be continued...

E~wee~ctor: writing tiny Effector from scratch #1 — Counter

Victor Didenko — Wed, 01 Apr 2020 21:11:15 +0000

Hi, all!

I really like "Implement something from scratch" type of articles, for example:

Lost with Redux and sagas? Implement them yourself!
Building Redux from scratch
Build your own React – this one is particularly awesome

It is a good way to learn how things work, and to unveil magic behind the black box of a library.

I plan to write a small Effector ☄️-like library called E~wee~ctor. This will be an educational-only purpose project.

Name "eweector" is derived from "effector" and "wee", meaning "little, small, tiny"
Second meaning of "wee" is also fit
Also my name is Victor and I like how "eweector" sounds :)

Good and simple place to start is a "counter" example from Effector website:

import {createStore, createEvent} from 'effector'

const add = createEvent()
const sub = createEvent()
const reset = createEvent()

const counter = createStore(0)
  .on(add, (count, n) => count + n)
  .on(sub, (count, n) => count - n)
  .reset(reset)

counter.watch(n => console.log('counter:', n))
// counter: 0
add.watch(n => console.log('add', n))
sub.watch(n => console.log('subtract', n))
reset.watch(() => console.log('reset counter'))

add(5)
// add 5
// counter: 5
sub(1)
// subtract 1
// counter: 4
reset()
// reset counter
// counter: 0

Thus we need to implement two main entities – event and store – and some of their methods.

I will not dive deeply into Effector right now, if you want to do it, check this article out. But here are some highlights from Effector's architecture:

Effector internally creates a graph of nodes
Nodes has (obviously) links to next nodes = edges of the graph
Any node can contain sequence of steps to run
A step can modify input data somehow, or stop branch computation, or launch some side-effect function
Upon some event Effector's kernel passes input data to a node and starts executing steps, using the breadth-first search algorithm
Any high-level Effector's unit (Event, Store, Effect, Domain) is a some object, attached to a node or bunch of nodes.

Here is the logical relationship graph for the code above:

And here is what Effector creates, structural graph of nodes:

Node

Let's start with the core thing of a graph – a node. A node should contain links to the next nodes – edges of a graph, and sequence of steps – where we will describe logic.

export const createNode = ({ next = [], seq = [] } = {}) => ({
  next,
  seq,
})

createNode factory function is very simple, it just creates a node object and nothing else. We could even go without it, and describe nodes in-place, like plain objects. But factory function gives us two benefits:

Each and every node it returns has same structure, so we will not miss some fields, defining them manually
ES6 syntax has very handy default parameters and destructuring assignment, and they can take burden of assigning default field values for node

Steps

Next thing we need is steps. There are six types of steps in Effector, but we will start from a single one. And we will not even create factory for it :) Let's just use function as a step. So out nodes will contain a sequence of functions to execute.

Event

Event is the simplest Effector unit. It is a function, attached to a graph node. The only purpose of an event as a high-level entity is to place input data into the node and to start computation cycle.

export const createEvent = () => {
  const event = payload => launch(event, payload)
  event.graphite = createNode()
  return event
}

createEvent factory creates function and attaches graph node into its graphite field. Created event-function accepts input data and executes function launch. This launch function will start a computation cycle, and we will describe it later, when we write a kernel.

As you can see, a node, attached to an event, doesn't have any next nodes, nor steps.

Watch

Before writing a kernel, let's implement watch functionality.

Watch is an auxiliary node, which runs side-effect. In case of our counter example this side-effect is console.log.

export const watch = unit => fn => {
  const node = createNode({
    seq: [fn],
  })
  unit.graphite.next.push(node)
}

watch function accepts two arguments (in a functional programming meaning) – unit to attach watch node, and function to execute.

As we decided to use simple functions as steps (for now) – we will just use given side-effect function as a step for watch node.

And after creating watch node, we put this node to the next array for the given unit.

And now let's add .watch method to our event:

export const createEvent = () => {
  const event = payload => launch(event, payload)
  event.graphite = createNode()
+  event.watch = watch(event)
  return event
}

So we will be able to watch events:

const event = createEvent()
event.watch(data => console.log(data))

Kernel

And here we go :) The kernel. It is not that frightening as it sounds, really.
There are two main parts of the kernel: queues and computation cycle.

Effector utilises five queues. We will start with single one:

// contains objects { node, value }
const queue = []

Computation cycle traverses graph and executes each step from each node:

const exec = () => {
  while (queue.length) {
    let { node, value } = queue.shift()
    node.seq.forEach(step => (value = step(value)))
    node.next.forEach(node => queue.push({ node, value }))
  }
}

In simple words function exec can be described as following steps:

While queue is not empty, take element from queue
Execute each step from node, with initial value from queue element
Put each node from next array to the queue, with new value
Go to 1.

One more thing – we need function launch for our events:

export const launch = (unit, value) => {
  queue.push({ node: unit.graphite, value })
  exec()
}

launch function just puts node and value into the queue, and starts computation cycle. Thats it.

Store

And last, but not least – a store.

export const createStore = defaultState => {
  let currentState = defaultState
  const store = {}

  store.graphite = createNode({
    seq: [value => (currentState = value)],
  })

  return store
}

createStore factory creates object, and attaches graph node into its graphite field, just like with an event. But store node has one step – it saves input data into an enclosured variable currentState.

We also need to implement few store's methods, like .on, .reset and .watch. Let's start with last one:

  store.watch = fn => {
    fn(currentState)
    return watch(store)(fn)
  }

.watch method for store is a bit different, than for an event – first time it is called it executes given function with current state, and then creates watch node.

  store.on = (event, fn) => {
    const node = createNode({
      next: [store.graphite],
      seq: [value => fn(currentState, value)],
    })
    event.graphite.next.push(node)
    return store
  }

.on method accepts an event (or any unit) and reducer function. Like .watch method it creates a new on node, with one step, where reducer is called. And places this new node before store node in the graph, so new value from reducer will be saved in the store node. Also it puts this new node to the next array for the given event (or unit).

  store.reset = event => store.on(event, () => defaultState)

.reset method is just shortcut to set initial state.

And we've done our first step in this journey. If we combine all these pieces together, we will get minimal working "eweector", which could run counter example. And what is more important – it follows Effector's architecture!

In next chapters we will grow up our infant. I'll try to cover all Effector's API in reasonable limits, so stay tuned ;)

I've created project on GitHub to help you follow the source code.
All code, described in this chapter, is committed in this commit.

Thank you for reading!

Effector: we need to go deeper

Victor Didenko — Thu, 19 Mar 2020 19:42:34 +0000

This is a script of my talk for the Effector meetup #1
You can find the slides here, and the video from the meetup here

⚠️ Note! Information in this article has been outdated a bit, and could be not specifically accurate. But overall architecture view is still relevant.

Hi, folks!

So, Effector. Why does anyone even need to look under the hood? Why go deeper? As you know, it can be dangerous, and you may get stuck in Limbo.

I'll tell you why I needed this knowledge and why it can be useful for you.

This is a photo from the 1966 24 Hours of Le Mans. Three Ford GT40s are finishing almost at the same time. Ford management wanted all three cars to cross the finish line together because this would make a perfect advertising photo.

When I create an effect and run it three times, I imagine it this way:

This effect launches three parallel asynchronous operations that work independently of each other. However, in some cases, it may be useful to coordinate them somehow, just like Ford management coordinated the cars at the 1966 24 Hours of Le Mans.

Let's say, you have an effect that submits a form to the server. When the user clicks the button, the effect is launched. But if the user clicks the button again, it's undesirable that the effect be launched for the second time. You have to either block the button or ignore any further clicks/effects.

A more interesting example is the auto-suggest function. When the user types in four letters, the effect launches to get suggestions from the server. However, if the user types in the fifth letter, the previous request is not relevant anymore. You have to cancel (or ignore) it and launch the effect again to get suggestions for a five-letter string.

It occurred to me that this is quite a frequent use case, so I wrote my own library called ReEffect, which slightly extends the effects from Effector adding a run strategy to them. I fully covered the code with tests, but when I tried to use my ReEffect with forward – it didn't work.

(Hey! I've written ReEffect. Yeah, but it doesn't work with forward. But… the tests…)
Just in case you’re curious, it works now, you can use it :)

I was in despair and asked Dmitry Boldyrev, the author of Effector, for help. He briefly told me about its internals and operation in general. And when I started to dig deeper, I began to realize that my understanding of Effector was like a pile of non-related pieces of a puzzle. It seemed simple, just four entities (event, store, effect, and domain) and 10-15 API methods. I could combine those pieces, glue them together by two or three, and use this Frankenstein's monster somehow. However, I didn't have the whole picture in my head, and the pieces didn't fit into the solved puzzle. Until I started to dig deeper.

I also hope that knowing how Effector works under the hood will help you to do this puzzle, if you have a similar pile of scattered puzzle pieces in your head as I did. It will help you to gain a clear understanding of Effector, or, at least, build the foundation for its understanding.

Let's start from afar. From the 18^th century :)

This is Leonhard Euler, mathematician, engineer, and scientist, who lived in the 18^th century. Once Euler was asked to solve a problem known as the Seven Bridges of Königsberg.

The city of Königsberg in Prussia (now Kaliningrad, Russia) was situated on both sides of the Pregel River and included two large islands – Kneiphof and Lomse – which were connected to each other, or to the two mainland portions of the city, by seven bridges. The problem was to devise a walk through the city that would cross each of those bridges once and only once.

If you don't know anything about this problem, you can stop here and try to find a solution :)

Euler found a solution and this solution is considered to be the first theorem of what now is called the graph theory.

Do you know what a graph is?

Imagine that each small circle in the image above is an object. Each structure in this image is called a graph. One object represents one vertex (or node) of the graph. The so-called list or bidirectional list is also a graph. A tree is a graph. Actually, any set of vertexes/nodes somehow connected with a set of edges (or links) is called a graph. There is nothing scary here.

I dare say you have already worked with graphs. A DOM tree is a graph. A database is a graph of tables and relations. Your friends and the friends of your friends on Facebook or VK form a graph. A file system is a graph (many modern file systems support hard links, and thus become "true" graphs, not trees). Wikipedia pages with internal links form a graph.

The whole human population of the Earth forms a huge graph of relationships, where you (yes, you, reader!) are just six (or fewer) social connections away from Donald Trump (as well as from Vladimir Putin). This is known as the 6 handshakes rule.

You may ask, how is all this related to Effector?

All Effector entities are connected in a graph! That's how!

If you think a bit and try to make logical connections between different entities, you will see it yourself.

Check out the following code:

const change = createEvent()
const onclick = change.prepend(
  e => e.target.innerText
)

const { increment, decrement } = split(change, {
  increment: value => value === '+',
  decrement: value => value === '-'
})

const counter = createStore(1)
  .on(increment, state => state + 1)
  .on(decrement, state => state - 1)

const foo = counter.map(state => state % 3 ? '' : 'foo')
const bar = counter.map(state => state % 5 ? '' : 'bar')
const foobar = combine(foo, bar,
  (foo, bar) => foo && bar ? foo + bar : null
)

sample({
  source: change,
  clock: foobar.updates.filterMap(value => value || undefined),
  target: change
})

Here is a working REPL, where you can try out this code online

Let's draw logical connections between different entities in this code:

In a slightly better way, the result looks as follows:

As you can see, this is a graph.

I'd like to emphasize that we haven't even looked under the hood yet, all we've done so far is draw logical connections between the Effector entities. And now we've got a graph.

The most exciting part is that Effector actually works this way!

Any entity generated by Effector creates a node (or nodes) in a structural graph. And any Effector API creates and/or connects different nodes in this structural graph.

And I think it is great! We have a logical graph of relationships between different entities. Why not implement it using a physical structural graph of some nodes?

And now, we will open the hood and look under it!

This is what an Effector node looks like:

You can check out this interface here. I just rewrote it from Flow to Typescript and renamed a little

An Effector node is just an object with the following fields:

next – links to the next nodes. These are the edges of our graph.
seq (from "sequence") – a sequence of steps for that node. The sequence of steps is what makes the types of nodes unique. We will take a closer look at the steps in a few minutes.
scope – arbitrary data necessary for the steps. This object will be passed to the step during the node execution.
reg (an unstable field that can be removed) – references to the stores necessary for the steps.
meta – arbitrary metadata, for example, the name of an entity is stored here.
family – describes the ownership graphs:
- type – the role of this node in each ownership graph.
- links – links to the nodes that belong to the given node. In other words, they indicate the nodes we need to delete when we delete this node.
- owners – links to the nodes that own the given node. That is to say, these links indicate the nodes from which we have to remove the link to the given node when we delete this node.

Thus you can see that we have more than one graph here: a computation graph (by links in the next field), two ownership graphs (by links in family.links and family.owners), and a graph of links to the stores (in the reg field).

Below, I will concentrate on fields next and seq, because these are the two main fields, where the logic of the whole process is described.

So, how does the Effector kernel work in a simple case?

Here are five nodes connected in a graph (in a tree configuration, but that's not the point). And at some moment, the data appears!

When the data is put in the node, this node is added to a queue, and the main cycle begins.
In each cycle iteration, the Effector kernel takes a node from the queue and executes all its steps.
Then the kernel adds all the nodes from next to the queue.
Then it repeats stages 2, 3 and 4 until there is nothing in the queue.

By the way, this graph transversal algorithm is called the breadth-first search. Effector uses a slightly modified breadth-first search algorithm with priorities. We will see it later.

Let's have a closer look at these three points:

What kind of data is it and how does it get into the node?
Various kinds of steps and how they differ
Queue

So, what kind of data is it and how does it get into the node?

The answer is events!

When you call an event (a simple function), all it does is send the payload to the graph and launch a computation cycle.

Also, of course, there are effects and stores.

You call an effect the same way you call an event (like a simple function) and thus send data into the graph. And when the operation is over, the resulting data also gets into the graph (into events/nodes .finally/.done/.fail).

The store has undocumented method .setState() that also transmits the payload to the graph. In fact, this doesn't differ much from the event.

But what exactly is an event?

An event is a simple function that receives the payload and calls function launch with itself and the received data. What is launch? launch is the only function exported by the Effector kernel and the only way to put data into the graph and launch a computation cycle.

"But what the heck, I can't see any nodes or graphs here!", – you might say. Well, that's because I haven't shown you the main thing:

Field .graphite:

This is where our node is located. It's a communication point and a bridge from the event function to the graph.

Any Effector API works with field .graphite (or if there is no such field, the Effector API thinks that it works with the node directly).

So, an event is a function with a node in field .graphite. A store is an object with a node in field .graphite. And an effect is also a function with a node in field .graphite (an effect is a complex entity that contains other nodes, but the main node – the bridge from the function and the entry point – is located in the .graphite field).

And here is an interesting thing – the Effector API doesn't care what exactly is connected to the node. It can be a function, like events and effects, or a plain object like a store, or an async generator, which yields values when its node receives the given value. Or this can be a field in a prototype chain, then all instances of a class will be connected to the same graph node (I don't know how this can be useful, though).

What are steps and how do they differ?

A step is just an object with field .type. Inside the Effector kernel, there is a big switch (step.type) that decides what to do depending on the type of the step. For convenience, the Effector package exports the step object to create different types of steps.

There are six types of steps:

compute – a step to do pure computations. It accepts input data and returns new transformed data. For example, the reducer function in store.on is launched inside the compute step. The map function in store.map also runs inside this step.
run – the same as compute, although aimed to execute side-effects. When the kernel meets step run, the computation for the node is postponed (I will show it later). Thus, any side-effects are executed after any pure computation. This step is used, for example, in watch nodes (yes, the .watch method creates a new node).
filter – a step to stop computations. It accepts input data and returns true or false values. And in case it's false, the branch of computation stops here, i.e. no further steps will be executed and the nodes from the next field will not be added to the queue. This step is used, for example, in .filter and .filterMap nodes.
barrier – a step with no logic, but this step either postpones the execution of the node or cancels it if the execution has already been postponed. This step is used in combine and sample.
check – a step with two checks:
- defined – checks that the input data is not undefined
- changed – checks that the input data is different from the data saved in the store
mov – a step with almost internal logic. I will not describe it here, but long story short, this step copies data from/to the store and/or internal stack fields. I call them registers, like registers in CPU, e.g. AX or BX.

Now, the queue. Or queues, because there are five of them in the Effector kernel :) Here is the difference from the usual breadth-first search algorithm – the nodes can be moved to a different queue under some conditions.

child – the nodes from field next are placed in this queue.
pure – the launch function will add a node/nodes to this queue.
barrier and sampler – two queues where the nodes with step barrier are placed.
effect – a queue where the nodes with step run are placed.

Queues have different priorities. In each iteration of the computation cycle, the kernel gets a node to process from the queue, depending on priority. So, top priority queue child is emptied first, and least priority queue effect is emptied last. Thus, the side-effects are always executed after pure computations.

Why do we even need different queues and priorities? Let's have a look at a common problem called the diamond dependency problem.

Another name for this problem is the glitches problem.

A glitch – is a temporary inconsistency in the observable state.

In essence, the problem is when there are many stores connected in a complex way, and a single update of one store can cause multiple updates of another store. Stores are frequently used in views, and fast multiple updates of one store cause useless view re-renders, and this looks like glitches, hence the name.

Here is a simple analogy with the Redux world: why do we even need to use memoized selectors? Because if we don't use them, any store update will cause the update of all the components, even if their data (part of the store) has not been updated.

Another example is from Rx world:

--a------b------c------d--------e--------
--1-------------2---------------3--------
           combineLatest
--a1-----b1-----(c1c2)-d2-------(e2e3)---

The events in parentheses happen "simultaneously". In practice, they happen at slightly different time periods separated only by a couple of nanoseconds. That's why people consider them to be simultaneous. Events (c1c2) are called glitches and sometimes thought to be a problem because one usually expects only c2 to happen.

So, what does Effector do to avoid this problem? This is one of the reasons why barriers and different priority queues exist.

Here is an example code:

const setName = createEvent()

const fullName = createStore('')
  .on(setName, (_, name) => name)

const firstName = fullName.map(
  first => first.split(' ')[0] || ''
)

const lastName = fullName.map(
  last => last.split(' ')[1] || ''
)

const reverseName = combine(
  firstName,
  lastName,
  (first, last) => `${last} ${first}`
)

reverseName.watch(
  name => console.log('reversed name:', name)
)

setName('Victor Didenko')

Event setName accepts the full name
The full name is set to store fullName
Two derived stores firstName and lastName are set automatically to the first and last name (the map function divides the full name with a space)
The combined store reverseName depends on stores firstName and lastName and joins their values in reverse order

Here is a question: will store reverseName be updated once (correctly) or twice (glitch)?

If you've checked the REPL, you already know the right answer. The store will be updated only once. But how does this happen?

Let's unfold this logical graph of relationships into a structural graph of Effector nodes:

Here is a full static view of the Effector graph:

Here you can see a few auxiliary nodes like .on between the event and the store, .map between the store and the derived store, and combine between the stores and the combined store. And that is where the beauty of Effector lies, in my opinion. You can perform any operation between entities/nodes by adding one or more auxiliary nodes with some logic. For example, forward just adds one node between two nodes. .watch only adds one new node. .on adds one auxiliary node between the event and the store. And if you want to perform operation .off, you just remove this intermediate node! Fascinating, isn't it?

The edges in this computation graph are drawn only by the links in field next. I didn't draw the ownership graphs, nor the graphs of links to the stores.

I will not explain each step in this graph (moreover, the implementation can be changed), but I want you to pay attention to a few things:

When you use API store.on(event, reduce) – the reduce function is executed inside intermediate node .on by the second step compute.
The current store value is copied to the intermediate node by the first step mov.
Intermediate nodes .map look exactly like node .on – in other words, this literally means that the derived store subscribes to the updates of the parent store. Just like the store subscribes to the event. There is one difference though – the map function gets a new value (from the parent store) as the first argument, as opposed to the reduce function, which gets a new value (from the event) as the second argument, and the current store value as the first one.
Any store has check.defined as the first step, so it is impossible to set an undefined value to the store.
Also there is a step check.changed in each store, so if the store value has not been changed by the new data, there will be no update to the next nodes in the graph.

And I'd like to describe step barrier in node combine in more detail. Here is the animation of solving the diamond problem:

What is going on, step by step:

At some point, we have two nodes in the child queue – firstName and lastName.
The kernel gets firstName and executes the node steps. Then it adds node combine to the child queue. Node .updates is also added, but it's a trivial process, so I'll ignore it here.
The kernel gets the next node lastName and executes the node steps. Then it also adds node combine (the same node) to the child queue. So, now we have two links to the same node in the queue.
The kernel gets node combine and executes the node steps until it meets step barrier.
When the kernel meets step barrier, it pauses the node execution and places this node to the barrier queue. The kernel also saves the barrier ID and the step index where the execution was paused.
Then the kernel gets node combine (the same node) from the child queue (because the child queue has higher priority than the barrier queue) and executes the node steps until it meets step barrier.
When the kernel meets step barrier, it pauses the node execution, but now it knows that there already is one postponed node in the barrier queue with the same barrier ID. So, instead of placing this node to the barrier queue again, the execution of this branch just stops here.
Please note that the execution stop is not throwing all computation results away. Node combine saves both the firstName value and the lastName value for this moment.
Now the child queue is empty, so the kernel gets node combine from the barrier queue and continues the execution from the step where it was paused.
Thus, only one execution branch of two gets through step barrier. So, this is how the diamond problem is solved. Store reverseName will get only one update.
If you are interested, the combine function is executed in step compute after step barrier – both values already exist here.

In Effector telegram chat, I saw a beautiful comparison of the computation cycle with lightning: calculations branch, diverge, converge, get cut and so on, but all these are parts of one single discharge.

And returning to the very beginning, why do you need to know the Effector internals?

If you search through the Effector documentation, you will not find any mention of the graphs (except for the Prior Art section). That is because you don't need to know the internal implementation to use Effector effectively. Sorry for the tautology. Your decision to choose one tool over another should be motivated by the task this tool aims to solve, and not by the tool's internal implementation. Effector solves any state manager problems like a boss, by the way ;)

But! There are always buts :)

Knowing what is going on under the hood, you can clean up the mess in your head if you do have it as I did. Imagine the whole picture, solve the puzzle, and build that racing car out of a pile of scattered pieces.

By the way, if you have some irrational fear of the word "graph", I can show you a mental lifehack for that:

You see the word "graph", you hear the word "network".

I'm serious, it is the same thing. But historically the term "network" is more widespread among engineers, not mathematicians.

This knowledge also gives you a bonus: you can create your own entities with your own logic that will work alongside with native Effector entities :)

I won't show you anything complex, but just a simple example: node future (I also call it a "porter"). It accepts any data and passes it further to the graph if it is not Promise. But if it is, the node holds it until Promise is resolved.

function createFuture () {
  const future = createEvent()
  future.graphite.seq.push(
    step.filter({
      fn(payload) {
        const isPromise = payload instanceof Promise
        if (isPromise) {
          payload
            .then(result => launch(future, { result }))
            .catch(error => launch(future, { error }))
        }
        return !isPromise
      }
    })
  )
  return future
}

const future = createFuture()
future.watch(_ => console.log('future:', _))

future(1)
future(new Promise(resolve => setTimeout(resolve, 100, 2)))
future(Promise.resolve(3))
future(Promise.reject(4))
future(5)

As you see, I took an ordinary event and modified its seq field, i.e. added one step filter. It is possible to create an entity with a node from scratch, but in that case, you should also think about implementing useful methods like .watch, .map, .prepend and so on. The event has them by default, so why not use them :)

The above code will print the following:

future: 1
future: 5
future: {result: 3}
future: {error: 4}
future: {result: 2}

And to finish, I'd like to put here an out-of-context quote by Linus Torvalds:

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

So, think about your tools.
Worry about data structures.

Thank you.

Forem: Victor Didenko

effector-storage v6

Contracts support

Exported adapters

Adapter utilities

async utility function

either utility function

farcached utility function

Adapter context

Force sync mode

Throttle/batch writes

Drop Effector v21 support

E~wee~ctor: writing tiny Effector from scratch #4 — Effect

E~wee~ctor: writing tiny Effector from scratch #3 — Simple API methods

forward

merge

split

createApi

is

restore

E~wee~ctor: writing tiny Effector from scratch #2 — Maps and Filters

Steps

Event.map

Event.prepend

Store.map

Event.filter

Event.filterMap

E~wee~ctor: writing tiny Effector from scratch #1 — Counter

Node

Steps

Event

Watch

Kernel

Store

Effector: we need to go deeper

`async` utility function

`either` utility function

`farcached` utility function