yanick/updux
1
0
Fork 0
Code Issues 6 Pull Requests Projects Releases 10 Wiki Activity

grammer, typos

Browse Source
This commit is contained in:
Trey Bianchini 2020-06-03 10:36:26 -05:00
parent f0653442f3
commit f8edbcaa49
1 changed files with 16 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
docs/tutorial.md
View File

@ -7,9 +7,9 @@ This tutorial assumes that our project is written in TypeScript, and
that we are using [updeep](https://www.npmjs.com/package/updeep) to that we are using [updeep](https://www.npmjs.com/package/updeep) to
help with immutability and deep merging and [ts-action][] to manage our help with immutability and deep merging and [ts-action][] to manage our
actions. This is the recommended setup, but actions. This is the recommended setup, but
none of those two architecture neither of those two architecture
decisions are mandatory; Updux is equally usable in a pure-JavaScript setting, decisions are mandatory; Updux is equally usable in a pure-JavaScript setting,
and `updeep` can easily be substitued by, say, [immer][], [lodash][], or even and `updeep` can easily be substitued with, say, [immer][], [lodash][], or even
just plain JavaScript. Eventually, I plan to write a version of this tutorial just plain JavaScript. Eventually, I plan to write a version of this tutorial
with all those different configurations. with all those different configurations.
@ -99,7 +99,7 @@ todosUpdux.addMutation( add_todo, todoMutation );
For TypeScript projects I recommend declaring the actions as part of the For TypeScript projects I recommend declaring the actions as part of the
configuration passed to the constructors, as it makes them accessible to the class configuration passed to the constructors, as it makes them accessible to the class
at compile-time, and allow Updux to auto-add them to its aggregated `actions` type. at compile-time, and allows Updux to auto-add them to its aggregated `actions` type.
``` ```
@ -213,7 +213,7 @@ todosUpdux.addMutation( '*', (payload,action) => state => {
## Effects ## Effects
In addition of mutations, Updux also provide action-specific middleware, here In addition to mutations, Updux also provides action-specific middleware, here
called effects. called effects.
Effects use the usual Redux middleware signature: Effects use the usual Redux middleware signature:
@ -259,7 +259,7 @@ todosUpdux.addEffect( add_todo, populate_next_id );
``` ```
As for the mutations, for TypeScript projects As for the mutations, for TypeScript projects
the use of `addEffect` is prefered, as the method gives visibility of the the use of `addEffect` is prefered, as the method gives visibility to the
action and state types. action and state types.
### Catch-all effect ### Catch-all effect
@ -301,7 +301,7 @@ todosUpdux.addSelector('getTodoById', ({todos}) => id => fp.find({id},todos));
``` ```
Here the declaration as part of the constructor configuration is prefered. Here the declaration as part of the constructor configuration is prefered.
Whereas the `addSelector` will provides the state's type as part of its Whereas the `addSelector` will provide the state's type as part of its
signature, declaring the selectors via the constructors will make them visible signature, declaring the selectors via the constructors will make them visible
via the type of the accessors `selectors`. via the type of the accessors `selectors`.
@ -349,7 +349,7 @@ const add_todo = action('add_todo', payload<string>() );
const add_todo_with_id = action('add_todo_with_id', const add_todo_with_id = action('add_todo_with_id',
payload<{ description: string; id: number }>() ); payload<{ description: string; id: number }>() );
const todo_done = action('todo_done', payload<number>() ); const todo_done = action('todo_done', payload<number>() );
const inc_next_id = action('inc_next_id'); const increment_next_id = action('increment_next_id');
const todosUpdux = new Updux({ const todosUpdux = new Updux({
initial: { initial: {
@ -360,7 +360,7 @@ const todosUpdux = new Updux({
add_todo, add_todo,
add_todo_with_id, add_todo_with_id,
todo_done, todo_done,
inc_next_id, increment_next_id,
}, },
selectors: { selectors: {
getTodoById: ({todos}) => id => fp.find({id},todos) getTodoById: ({todos}) => id => fp.find({id},todos)
@ -371,7 +371,7 @@ todosUpdux.addMutation( add_todo_with_id, payload =>
u.updateIn( 'todos', todos => [ ...todos, { ...payload, done: false }] ) u.updateIn( 'todos', todos => [ ...todos, { ...payload, done: false }] )
); );
todosUpdux.addMutation( inc_next_id, () => u({ next_id: i => i + 1 }) ); todosUpdux.addMutation( increment_next_id, () => u({ next_id: i => i + 1 }) );
todosUpdux.addMutation( todo_done, id => u.updateIn( todosUpdux.addMutation( todo_done, id => u.updateIn(
'todos', u.map( u.if( fp.matches({id}), todo => u({done: true}, todo) ) ) 'todos', u.map( u.if( fp.matches({id}), todo => u({done: true}, todo) ) )
@ -401,25 +401,25 @@ import { action, payload } from 'ts-action';
import u from 'updeep'; import u from 'updeep';
import fp from 'lodash/fp'; import fp from 'lodash/fp';
const inc_next_id = action('inc_next_id'); const increment_next_id = action('increment_next_id');
const updux = new Updux({ const updux = new Updux({
initial: 1, initial: 1,
actions: { actions: {
inc_next_id, increment_next_id,
}, },
selectors: { selectors: {
getNextId: state => state getNextId: state => state
} }
}); });
updux.addMutation( inc_next_id, () => fp.add(1) ); updux.addMutation( increment_next_id, () => fp.add(1) );
export default updux.asDux; export default updux.asDux;
``` ```
Notice that here we didn't have to specify what is the type of `initial`; Notice that we didn't have to specify the type of `initial`;
TypeScript figures by itself that it's a number. TypeScript figures by itself that it's a number.
Also, note that we're exporting the output of the accessor `asDux` instead of Also, note that we're exporting the output of the accessor `asDux` instead of
@ -564,9 +564,9 @@ Tadah! We had to define the `add_todo` effect at the top level as it needs to
access the `getNextId` selector from `next_id` and the `add_todo_with_id` access the `getNextId` selector from `next_id` and the `add_todo_with_id`
action from the `todos`. action from the `todos`.
Note that the `getNextId` selector still get the Note that the `getNextId` selector still gets the
rigth value; when aggregating subduxes selectors Updux auto-wrap them to right value; when aggregating subduxes selectors Updux auto-wraps them to
access the right slice of the top object. I.e., the `getNextId` selector access the right slice of the top object. i.e., the `getNextId` selector
at the main level is actually defined as: at the main level is actually defined as:
``` ```