		{
		"devDependencies": {
		"ava": "^3.15.0",
		"esm": "^3.2.25"
		"esbuild": "^0.11.12"
		},
		"name": "quarx",
		"version": "1.0.0",
		"version": "1.0.1",
		"description": "Simple dependency graph engine, MobX inspired",
		"main": "index.js",
		"main": "dist/index.js",
		"module": "index.js",
		@@ -17,10 +17,10 @@ "types": "index.d.ts",
		"scripts": {
		"test": "ava -v"
		"build": "esbuild index.js --bundle --platform=node --outfile=dist/index.js",
		"test": "ava -v",
		"perf": "ava -v --config test.perf.config.js --node-arguments='--expose-gc'"
		},
		"ava": {
		"files": [
		"*/.spec.js"
		],
		"require": [
		"esm"
		"*/.spec.js",
		"!tests/perf.spec.js"
		]
		@@ -27,0 +27,0 @@ },

README.md

		@@ -1,2 +0,2 @@
		# ❉ Quarx
		# 🜉 Quarx
		Simple tiny dependency graph engine, MobX inspired
		@@ -10,4 +10,39 @@

		Unlike MobX, Quarx does not support circular computations even if they might eventually settle. It is a deliberate design decision that allowed for dramatic algorithm simplification, as well as enabled nested reactions execution. MobX on the other hand always delays the execution of nested reactions until the parent reaction exits: a leaky abstraction IMO.
		Unlike MobX, Quarx does not support circular computations even if they might eventually settle. This deliberate design decision allowed for dramatic algorithm simplification while circular calculation graphs do little to promote code clarity.

		Another difference with MobX, and the primary reason Quarx saw the light of day is that Quarx always runs the computation immediately and synchronously when `autorun` is called, while MobX always delays the execution of nested reactions until the parent reaction exits.

		With greedy execution, one can create new observed atoms on the fly (from within a reaction), paired with an `autorun` that should synchronously hydrate the atom at creation. This is by the way exactly how `computed` is implemented in Quarx.

		## Usage example
		```js
		import { autorun, computed, observable, batch } from 'quarx';

		const a = observable.box(1);
		const b = observable.box(2);
		const a_plus_b = computed(() => a.get() + b.get());

		console.log('Initial calculation');
		autorun(() => console.log(`a + b = ${a_plus_b.get()}`));

		console.log('First update');
		batch(() => {
		a.set(5);
		b.set(6);
		});

		console.log('Second update');
		batch(() => {
		a.set(4);
		b.set(7);
		});

		// * Prints *
		// Initial calculation
		// a + b = 3
		// First update
		// a + b = 11
		// Second update
		```

		## Low-level concepts
		@@ -23,3 +58,3 @@ There are 2 core primitive abstractions in Quarx: computations and atoms.

		During a single synchronous re-actualization (hydration) run of the DAG each computation would be calculated at most once.
		During a single synchronous re-actualization (hydration) run of the DAG each computation would be executed at most once.

		@@ -64,5 +99,5 @@ ```typescript
		```
		Please refer to the [API reference]((https://github.com/dmaevsky/quarx/blob/master/index.d.ts)) for more detail.
		Please refer to the [API reference](https://github.com/dmaevsky/quarx/blob/master/index.d.ts) for more detail.

		Box observables are the upstream leaves of the computations DAG. `aBox.get()` reports the box observed to the calling computation, and `aBox.set(value)` will report it changed if the `value` is different from the current one in the sense of the `equal` option (`===` by default).
		Box observables are the upstream leaves of the computations DAG. `aBox.get()` reports the box observed to the calling computation, and `aBox.set(value)` will report it changed if the `value` is different from the current one in the sense of the `equal` option (`===` by default). A Box in Quarx is never trying to make its content deeply observable like MobX. It represents a single observable value.

		@@ -75,11 +110,9 @@ Computed observables are the intermediate nodes of the DAG representing the reactive derivations. `aComputed.get()` returns the result of the computation. If the computation threw an error, the `computed` will store it and re-throw on `get()`. Only if the computation result is different from the previously computed one in the sense of the `equal` option (`===` by default), the change will be reported downstream.

		## Future development
		At least an `observable.map` would likely be shipped as part of Quarx. The goal is however to keep the core as tiny as possible.

		## Goals and non-goals
		Quarx strives to remain a dry essence of a dependency graph engine. It will replace MobX in production at [ellx.io](https://ellx.io) shortly.
		The goal for Quarx is to remain a dry essence of a dependency graph engine. As simple and tiny as it is, it will replace MobX in production at [ellx.io](https://ellx.io) shortly.

		Out of the box, Quarx is not a state management solution. However, I'd encourage you to try using it in combination with [Tinyx](https://github.com/dmaevsky/tinyx). Just put the root Tinyx store into a single `observable.box`, and derive the rest of the state reactively with a network of `computed` selectors.
		Out of the box, Quarx is not designed to be a state management solution. However, it can be used in combination with [Tinyx](https://github.com/dmaevsky/tinyx) or even Redux. Just put the root store into a single `observable.box`, and derive the rest of the state reactively with a network of `computed` selectors.

		#### NOTE
		On a side note...

		Converting an Observable to a Svelte store is a one-liner:
		@@ -86,0 +119,0 @@ ```js

quarx - npm Package Compare versions

New alerts

Fixed alerts

Improved metrics