repos / starfx

commit

78650a3

parent

b0613a8

author

Eric Bower

date

2023-12-01 02:49:41 +0000 UTC

docs: readme

 1@@ -22,20 +22,35 @@ Read my introductory blog post:
 2 
 3 # design philosophy
 4 
 5-- side-effect management is a first-class citizen
 6+- side-effect management is the central processing unit for side-effects, state,
 7+  and the view
 8 - leverage structured concurrency to manage side-effects
 9-- business logic lives outside the view layer
10-- state management is just a side-effect of user interaction
11-- state management should not be coupled to the view
12+- side-effect and state management decoupled from the view layer
13 - full control over state management
14+- state is just a side-effect of user interaction and app features
15+- state management should not be coupled to the view
16 
17 # example: thunks are tasks for business logic
18 
19+Thunks are the foundational central processing units. They have access to all
20+the actions being dispatched from thew view -- or other thunks. They also wield
21+the full power of structured concurrency.
22+
23+Every thunk that is created requires a unique id -- user provided string. This
24+provides us with a handful of benefits:
25+
26+- User hand-labels each task created (intention)
27+- Better tracability (via labels)
28+- Easier to debug async and side-effects in general (via labels)
29+- Build abstractions off naming conventions (e.g. creating routers
30+  `/users [GET]`)
31+
32 They also come with built-in support for a middleware stack (like `express`).
33 This provides a familiar and powerful abstraction for async flow control for all
34 thunks and endpoints.
35 
36-Why does the BE get to enjoy middleware but not the FE?
37+You didn't know you wanted express middleware for the front-end, but let me get
38+you excited, it's powerful.
39 
40 ```ts
41 import { createThunks, mdw } from "starfx";