Skip to content

Commit e928a3d

Browse files
committed
docs (readme): update state to store
1 parent fb695b5 commit e928a3d

File tree

1 file changed

+19
-19
lines changed

1 file changed

+19
-19
lines changed

README.md

Lines changed: 19 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -34,14 +34,14 @@ Easy State supports [Create React App](https://github.com/facebookincubator/crea
3434

3535
Easy State consists of two functions:
3636

37-
- `easyComp` makes React's own component level state management simpler.
37+
- `easyComp` makes component level state management simpler.
3838
- `easyStore` creates global state stores for complex apps.
3939

4040
### easyComp
4141

4242
Wrapping your components with the `easyComp` function provides the following benefits.
4343

44-
- It allows you to mutate the component's state directly, without calling `setState`.
44+
- It adds a local `store` to the component, which can be handled as a simple JS object.
4545

4646
- It binds your component's methods to the component.
4747

@@ -50,20 +50,20 @@ import React, { Component } from 'react'
5050
import { easyComp } from 'react-easy-state'
5151

5252
class Hello extends Component {
53-
state = {
53+
store = {
5454
name: 'World'
5555
}
5656

5757
// this is bound to the component, so it can be safely passed as a callback
5858
onChange (ev) {
59-
// the state can be modified directly
60-
this.state.name = ev.target.value
59+
// the store can be modified directly
60+
this.store.name = ev.target.value
6161
}
6262

63-
// the render is triggered whenever state.name changes
63+
// the render is triggered whenever store.name changes
6464
render () {
6565
const { onChange } = this
66-
const { name } = this.state
66+
const { name } = this.store
6767

6868
return (
6969
<div>
@@ -82,29 +82,29 @@ export default easyComp(Hello)
8282

8383
In addition to the boilerplate reduction, `easyComp` comes with a bunch of additional benefits that may not be obvious at first glance.
8484

85-
- The state becomes a simple object, which updates synchronously. You don't have to worry about immutable state updates or the asynchronous nature of `setState`. If you are not sure about the meaning of this check out [this article](https://medium.freecodecamp.org/functional-setstate-is-the-future-of-react-374f30401b6b) about `setState`.
85+
- The store is simple object. You don't have to worry about immutable state updates or the asynchronous nature of `setState`. If you are not sure about the meaning of this check out [this article](https://medium.freecodecamp.org/functional-setstate-is-the-future-of-react-374f30401b6b) about `setState`.
8686

87-
- The render method is only triggered if it is affected by the state mutations. If it doesn't use the mutated part of the state or the mutation doesn't change the state, the render method is not triggered.
87+
- The render method is only triggered if it is affected by store mutations. If it doesn't use the mutated part of the store or the mutation doesn't change the store, the render method is not triggered.
8888

8989
- The render method is never executed immediately. Triggered renders are collected and executed asynchronously in one batch.
9090

9191
- Renders always run before the next repaint.
9292

9393
- Duplicates renders are removed. A render never runs twice in one batch - no matter how many times it got triggered.
9494

95-
- Renders may trigger others renders by mutating the state. In this case loops are automatically resolved.
95+
- Renders may trigger others renders by mutating the store. In this case loops are automatically resolved.
9696

9797
- Easy State implements an optimal `shouldComponentUpdate` for your components.
9898

99-
As a result the state is always fresh and a stable and a fresh view is always achieved before the next repaint with the minimal number of required renders.
99+
As a result the store is always fresh and a stable and a fresh view is always achieved before the next repaint with the minimal number of required renders.
100100

101101
### easyStore
102102

103-
`easyStore` creates global state stores, to handle data that do not fit into component state. Wrapping an object with `easyStore` has to following effects.
103+
`easyStore` creates global state stores, to handle data that does not fit into component stores. Wrapping an object with `easyStore` has to following effects.
104104

105-
- It transforms the object into a reactive data store, which triggers appropriate renders on mutations.
105+
- It transforms the object into a reactive data store, which triggers appropriate renders on mutations. This store is just a simple object.
106106

107-
- It binds your object's methods to the object.
107+
- It binds your store's methods to the store.
108108

109109
```js
110110
import React from 'react'
@@ -135,7 +135,7 @@ function Hello () {
135135
export default easyComp(Hello)
136136
```
137137

138-
**Make sure to wrap your component with `easyComp` even if it uses global stores only and no local state.**
138+
**Make sure to wrap your component with `easyComp` even if it uses global stores only and no local stores.**
139139

140140
- Global stores are simple objects and there is no limitation on what you can do with them. As an example feel free to use expando properties, arrays, deeply nested objects, ES6 collections or getters/setters in your stores.
141141

@@ -178,11 +178,11 @@ The list of benchmarks will expand in the future.
178178

179179
## State management overview
180180

181-
Finding the right balance between local component state and global state stores is not always a trivial task. This section gives you some general guide lines when to use which.
181+
Finding the right balance between local component stores and global state stores is not always a trivial task. This section gives you some general guide lines when to use which.
182182

183183
### Reusable widgets
184184

185-
This is an easy decision. Always use local component state for reusable components. Depending on global stores would interfere with their reusability and break them. Check out the introductory [clock example](/examples/clock/) for some code.
185+
This is an easy decision. Always use local component stores for reusable components. Depending on global stores would interfere with their reusability and break them. Check out the introductory [clock example](/examples/clock/) for some code.
186186

187187
### Application state
188188

@@ -192,9 +192,9 @@ Application state should usually be managed in global stores. It is singleton an
192192

193193
- User inputs, which should go into the URL or change the browser history are also great examples. These are inherently global because they affect global concepts - like the URL and browser history. Some example for these are filters, date ranges and sorting primitives.
194194

195-
Not everything fits in global stores though. You can find a few cases below when using the local component state makes more sense then global stores.
195+
Not everything fits in global stores though. You can find a few cases below when using the local component store makes more sense then global stores.
196196

197-
- Utility and meta data should go into component state. For example you may have a component which handles recent history for an input field. It may make sense to receive the data for the input from a global store and manage the history meta data in the local state. Check out the [contacts table example](/examples/contacts/) for some code.
197+
- Utility and meta data should go into component stores. For example you may have a component which handles recent history for an input field. It may make sense to receive the data for the input from a global store and manage the history meta data in the local store. Check out the [contacts table example](/examples/contacts/) for some code.
198198

199199
### Application pages
200200

0 commit comments

Comments
 (0)