Fork me on GitHub
#fulcro
<
2019-05-05
>
eoliphant15:05:02

Hi, are there any examples of using the form-state stuff with pathom resolvers on the server?

currentoor20:05:55

The two typically have very different concerns that don’t overlap

eoliphant20:05:07

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

currentoor20:05:46

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)

currentoor20:05:50

are you using datomic?

currentoor20:05:25

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 ...]

currentoor20:05:02

and i have a function that takes generic results from fs/dirty-fields and turns it into a datomic transaction

eoliphant20:05:06

yeah datomic on the back end

eoliphant20:05:34

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

eoliphant20:05:28

I can see that working, but in that case, are you doing a more generic pathom mutation that ‘understands’ the dirty-fields format?

eoliphant20:05:06

and yeah, what you describe would work for me, my app db is organized around the idents in the db

currentoor22:05:07

well since my backend lookup refs and client side idents are identical, it works out nicely

currentoor22:05:11

this is my generic function on the backend

eoliphant22:05:13

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?

currentoor22:05:40

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}))

eoliphant22:05:51

ok sweet that makes sense

currentoor22:05:59

where delta is the result of fs/dirty-fields

currentoor22:05:22

but some of my mutations require special casing/extra-checks/work

currentoor22:05:29

so i have named mutations for each one

eoliphant22:05:52

gotcha, now those are fulcro server vs pathom mutation though right?

currentoor22:05:35

it doesn’t matter what they are, no?

currentoor22:05:07

they happen to be pathom mutations in this project, but i don’t see how that would affect this approach in any way

eoliphant22:05:19

gonna have to rethink my approach a little to handle a more generic ‘create-firm’ vs one thats form state aware.

eoliphant22:05:57

ah yeah yeah you’re right, ultimately wouldn’t make a diff

eoliphant22:05:55

was thinking more about the params etc metadata in pathom

currentoor22:05:59

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

currentoor22:05:28

that said, you know your domain way better than i do simple_smile

eoliphant22:05:48

yeah, that’s what I’ve been back and forth with, and I do have a nasty over engineering tendency lol

eoliphant22:05:23

but given the ease with which you can say refactor out some verbosity

eoliphant22:05:35

once some actual patterns have emerged

eoliphant22:05:00

vs trying to over anticipate them , certainly makes sense lol

currentoor22:05:01

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

eoliphant23:05:18

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

eoliphant23:05:02

so at some level, I’ll end up with more data points, faster in terms of what could use a bit more attention

eoliphant23:05:05

but thanks a mil for that, saves me a bit of headache lol

👍 4
currentoor23:05:42

happy to help

hmaurer20:05:53

@eoliphant hi! what exactly are you trying to do?

eoliphant20:05:08

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