I have om.next app and am building two different sets of mutate/read fns 
because I want to have switchable persistence.

I am pondering over the design of the coupling between the UI and the data 
layer and in particular — how to ensure that I spot as early and reliable as 
possible inconsistencies between the persistence implementations and the UI.

Example: changing the data structure by adding a field, putting this in the UI 
but forgetting to adapt one of the read functions. I've considered using 
clojure.spec in a thin repository layer that only validates the data coming 
from the persistence implementation, however the general message I've heard is 
that clojure.spec is not supposed to be used in production mode.

What's your advice on structuring the mutation functions? Is it advisable to 
use om/transact! directly in the UI code, or do you have some API (like 
Repository pattern) that hides the details?

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/clojurescript.

Reply via email to