Merge branch 'develop'

This commit is contained in:
Mike Thompson 2017-07-17 09:57:08 +10:00
commit 4b3da7e4ff
2 changed files with 3 additions and 2 deletions

View File

@ -30,7 +30,7 @@ namespaces. To the Google Closure dependency mechanism it appears as
if these two namespaces are not needed and it doesn't load them. if these two namespaces are not needed and it doesn't load them.
And, if the code does not get loaded, the registrations in these namespaces And, if the code does not get loaded, the registrations in these namespaces
never happen. You'll then you'll be puzzled as to why none of your events handlers never happen. You'll then be puzzled as to why none of your events handlers
are registered. are registered.
Once you twig to what's going on, the solution is easy. You must Once you twig to what's going on, the solution is easy. You must
@ -44,6 +44,7 @@ Assuming your larger apps have multiple "panels" (or "views") which are
relatively independent, you might use this structure: relatively independent, you might use this structure:
``` ```
src src
├── core.cljs <--- entry point, plus history, routing, etc
├── panel-1 ├── panel-1
│ ├── db.cljs <--- schema, validation, etc (data layer) │ ├── db.cljs <--- schema, validation, etc (data layer)
│ ├── subs.cljs <--- subscription handlers (query layer) │ ├── subs.cljs <--- subscription handlers (query layer)

View File

@ -289,7 +289,7 @@ In note form:
1. Event handlers should only return effect declaratively 1. Event handlers should only return effect declaratively
2. They return a map like `{:effect1 value1 :effect2 value2}` 2. They return a map like `{:effect1 value1 :effect2 value2}`
3. Keys of this map can refer to builtin effects handlers (see below) or custom ones 3. Keys of this map can refer to builtin effects handlers (see below) or custom ones
4. We use `reg-fx` to register our own effects handlers 4. We use `reg-fx` to register our own effects handlers, builtin ones are already registered
### Builtin Effect Handlers ### Builtin Effect Handlers