This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-05
Channels
- # beginners (12)
- # calva (18)
- # cider (1)
- # cljs-dev (29)
- # clojure (97)
- # clojure-uk (18)
- # clojurescript (10)
- # clojureverse-ops (2)
- # cursive (7)
- # emacs (10)
- # fulcro (42)
- # graphql (36)
- # joker (1)
- # juxt (28)
- # mount (2)
- # other-languages (2)
- # pathom (1)
- # portkey (3)
- # re-frame (50)
- # shadow-cljs (42)
- # spacemacs (4)
- # sql (6)
- # yada (6)
Hi, are there any examples of using the form-state stuff with pathom resolvers on the server?
The two typically have very different concerns that don’t overlap
yeah that’s what I’m grappling with lol. my server mutations are a more well ‘generic’ api, where the form state is understanding the diff, etc but I’m not sure of the best appraoch to munging the fs stuff into what the server expects. and I obviously don’t want the server to know about say my client xxx/by-id
tables etc
i don’t think it’s the worst thing in the world if your server knows a little bit about the client-app state (specifically how it normalizes things)
are you using datomic?
for a given form i’m sending the result of fs/dirty-fields
to the server, which is normalized by ident (my idents are the same as datomic lookup refs [:user/id ...]
and i have a function that takes generic results from fs/dirty-fields
and turns it into a datomic transaction
well my only concern is that, I’m trying to make my mutations somewhat generic (in terms of clients), such that another app/system might create a foo
I can see that working, but in that case, are you doing a more generic pathom mutation that ‘understands’ the dirty-fields
format?
and yeah, what you describe would work for me, my app db is organized around the idents in the db
well since my backend lookup refs and client side idents are identical, it works out nicely
this is my generic function on the backend
yeah i can see that, but again, are you using like a ‘generic’ mutation or do each of your say update-foo
, update-bar
mutations handle the denorm etc?
the latter
most of my mutations look like this
(defmutation create-firm
[{:keys [conn]} {:keys [delta firm/id]}]
{:policy s.policy/admin}
(let [txn (fs+/delta->datomic-txn delta)]
@(d+/transact conn txn)
{:firm/id id}))
where delta is the result of fs/dirty-fields
but some of my mutations require special casing/extra-checks/work
so i have named mutations for each one
it doesn’t matter what they are, no?
they happen to be pathom mutations in this project, but i don’t see how that would affect this approach in any way
gonna have to rethink my approach a little to handle a more generic ‘create-firm’ vs one thats form state aware.
IMO there’s a very high price to pay for the wrong abstraction and a moderate cost to being more verbose than necessary, i wouldn’t try to handle all models generically
that said, you know your domain way better than i do
yeah, that’s what I’ve been back and forth with, and I do have a nasty over engineering tendency lol
i try to let things stay a little verbose and let them marinate with new business requirements, then abstract away afterwards when clear patterns and exceptions have emerged
yeah the thing is that i’m working on a dreaded ‘framework’ lol, but actually even there, I’d agree that what you’re saying holds. Even now it’s fairly useful on 3 disparate projects
so at some level, I’ll end up with more data points, faster in terms of what could use a bit more attention
happy to help
@eoliphant hi! what exactly are you trying to do?
hey just basically send say my (create/update-foo ..)
mutation. On the server at the moment my say update-foo
is expecting a foo map. The way the form-state dirty fields makes sense in terms of all the diffing and what have you, but OTOH, sending that would seem to bind my server mutation to the client very tightly since now info about the normalized table, etc is going over the wire
@eoliphant see this gif