After the appearance of React in the browser landscape the community built numerous libraries like Om, Om Next, Reagent (used with or without Re-frame), Quiescent, Reacl and perhaps even more to make Reacts blessings available in ClojureScript. Some libraries clearly express their preferences about how a more complete frontend architecture should look like, and encourage us to add core.async, co-located queries, reactive programming or cursors to the mix. Based on an understanding of the general problems to be solved within a single-page-application this talk will provide some design heuristics on how to make the right choices that add just enough complexity to your frontend.

1. Making design decisions in
React-based ClojureScript web
applications
@friemens

3. React
Component
hierarchy
DOMVDOM
Callback
Render

4. How do I organize state and presentation logic?
Component
hierarchy
DOMVDOM
Callback
Render
?

5. App state: One or many atoms?
Component
hierarchy
Or put everything
into one atom?
Partition state
by components?

6. App state: Same information in different places
Component
hierarchy
App state

7. App state: Structural mismatches
Component
hierarchy
App state

8. App state: Unpredictable data needs
Dynamic,
user-driven
screen

9. App state: Update state after events
Update state
directly?
HTML inputApp state
Or send an
'update' event?
Component-external code

10. 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] state­or­channel→

11. The Big LoopTM
App state
Component
hierarchy
DOMVDOM
Presentation
logic
Remote backend
Events
Dispatcher
Channel

12. The Om/Next (Relay+Falcor inspired) approach
Q
Q
Q
Q
Query Tree
Q
Backend
Tree-ish data
Q
Q
Q
Q
Q
Components +
co-located queries

13. 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 query
endpoint might even then
be beneficial.
Top-level components decide
upon queries and push
state to child components.

14. Dataflow
observe
compute
App state
Derived state
Component hierarchy

15. Cursor
A value combining
●
pointer to a ref
●
a path
2
1
2 1
CursorApp state

16. 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 logic
knows locations in root atom.
no
yes
It's not hard to make
components reusable.

17. How to synchronize app state with your backend?
Remote backend App state
Asynchronous
communication

18. Synchronization of state with your backend
Handle asynchronity with your event channel
App state
Presentation
logic
Remote backend Dispatcher
Channel
Other Events
Async response

19. Synchronization: Inconsistencies after errors
FrontendBackend

20. Combine many logical requests in one roundtrip
App state
Presentation
logic
Remote backend
request 1
request 2
request 3
response 1
response 2
response 3

21. FrontendBackend
Query data after update in same network roundtrip

22. User input while in synchronization
Database
User +
Frontend
Time
edit
query
edit
update + query
?

23. 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?

24. Synchronization: Concurrency control
Time
Database
User A
User B
query
edit
update
query
update
?

25. Synchronization: Concurrency Control
Optimistic Concurrency Control
a.k.a Version numbers
v0v0 v1
v0
v0
v0
v1
v0
Time
Database
User A
User B

26. Synchronization: Concurrency Control
Pessimistic Concurrency Control
a.k.a Locking
Time
Database
User A
User B

27. 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 pessimistic
concurrency control?
It really depends on your domain!

28. Wrap up

29. Wrap up
Optimistic or pessimistic
concurrency control?
How (un)predictable are your data needs?
Do your components require expensive data transformations?
Examine decisions that your favorite
React-wrapping lib has made on behalf of you!

30. Thank you for listening!
Questions?
@friemens www.doctronic.de