state-tree - npm Package Compare versions

Comparing version 0.1.4 to 0.1.6

package.json

		{
		"name": "state-tree",
		"version": "0.1.4",
		"version": "0.1.6",
		"description": "A state tree that handles reference updates and lets you flush a description of changes",
		@@ -5,0 +5,0 @@ "main": "src/index.js",

README.md

		@@ -1,2 +0,2 @@
		# state-tree
		# state-tree (EXPERIMENTAL)
		A state tree that handles reference updates and lets you flush a description of changes
		@@ -7,4 +7,6 @@

		- One state tree. It just keeps a much clearer mental image and I never get into circular dependencies with my state models. It is also easier to hydrate and rehydrate the state of my app
		- One state tree. It just keeps a much clearer mental image and I never get into circular dependencies with my state models. It is also easier to hydrate and dehydrate the state of my app

		- Control changes. I want a simple way to track the changes made to the app. By using a `state.set('some.state', 'foo')` API instead of `some.state = 'foo'` this control becomes more intuitive as you have a specific API for making changes, rather than "changing stuff all over". It also makes it a lot easier to implement tracking of any changes

		- Fast updates. Immutability has benefits like being able to replay state changes, undo/redo very easily and no unwanted mutations in other parts of your code. The problem though is that immutability is slow on instantiating large datasets
		@@ -11,0 +13,0 @@

New alerts