making design decisions in react-based clojurescript web applications
TRANSCRIPT
Making design decisions in React-based ClojureScript web
applications
@friemens
React
Componenthierarchy
DOMVDOM
Callback
Render
How do I organize state and presentation logic?
Componenthierarchy
DOMVDOM
Callback
Render
?
App state: One or many atoms?
Componenthierarchy
Or put everythinginto one atom?
Partition stateby components?
App state: Same information in different places
Componenthierarchy
App state
App state: Structural mismatches
Componenthierarchy
App state
App state: Unpredictable data needs
Dynamic, user-driven
screen
App state: Update state after events
Update state directly?
HTML inputApp state
Or send an 'update' event?
Component-external code
Where to start
● Keep frontend state in single atom
● Keep components stupid● Move presentation logic out of your components● Provide a communication channel to components● Avoid component assumptions about your state
● Presentation logic is a set of functions[state event] stateorchannel→
The Big LoopTM
App state
Componenthierarchy
DOMVDOM
Presentationlogic
Remote backend
Events
DispatcherChannel
The Om/Next (Relay+Falcor inspired) approach
Q
Q
Q
Q
Query Tree
QBackend
Tree-ish data
QQQ
Components +co-located queries
Do I need the Om/Next approach?
Unpredictable data needs?
Provide an endpoint accepting GraphQL-style queries.
Co-locate your queries with your components.
yesno
Having a generic queryendpoint might even then be beneficial.
Top-level components decide upon queries and pushstate to child components.
Dataflow
observe
compute
App state
Derived state
Component hierarchy
Cursor
A value combining ● pointer to a ref● a path
2
1
2 1
CursorApp state
Do I need dataflow and/or cursors?
Structural mismatches?Transformations?
Add dataflow.
Keep it simple,use cursors.
Need reusable components on derived state?
Make sure update logicknows locations in root atom.
noyes
It's not hard to makecomponents reusable.
How to synchronize app state with your backend?
Remote backend App state
Asynchronouscommunication
Synchronization of state with your backend
Handle asynchronity with your event channel
App state
Presentationlogic
Remote backend DispatcherChannel
Other Events
Async response
Synchronization: Inconsistencies after errors
FrontendBackend
Combine many logical requests in one roundtrip
App state
Presentationlogic
Remote backend
request 1request 2request 3
response 1response 2response 3
FrontendBackend
Query data after update in same network roundtrip
User input while in synchronization
Database
User +Frontend
Time
edit
query
edit
update + query
?
User input while in synchronization
Don't.Lock your UI.
Merge user input with loaded data.
How should I handle user input while loading
data?
Synchronization: Concurrency control
Time
Database
User A
User B
query
edit
update
queryupdate
?
Synchronization: Concurrency Control
Optimistic Concurrency Control a.k.a Version numbers
v0v0 v1
v0
v0
v0
v1
v0
Time
Database
User A
User B
Synchronization: Concurrency Control
Pessimistic Concurrency Control a.k.a Locking
Time
Database
User A
User B
Synchronization: Concurrency Control
Version numbers+ conflicts unlikely+ loosing work is acceptable+ cheap- affects your data
Locking+ safety-first approach- lock management- dead client detection
Optimistic or pessimisticconcurrency control?
It really depends on your domain!
Wrap up
Wrap up
Optimistic or pessimisticconcurrency control?
How (un)predictable are your data needs?
Do your components require expensive data transformations?
Examine decisions that your favoriteReact-wrapping lib has made on behalf of you!
Thank you for listening!
Questions?
@friemens www.doctronic.de