Fork me on GitHub
#fulcro
<
2020-03-01
>
dvingo05:03:34

ughhhhh - I had "Socket REPL" selected instead of nREPL....

Jakub Holý (HolyJak)08:03:35

Same here :) It seems Socket is the default.

uwo20:03:01

question about RAD's ::attr/target. The docs mention that target is required if the attr is of type :ref, however we have many component refs that do not have their own identity attr. How should we work around this requirement?

uwo20:03:13

when we need to handle such entities directly, we just walk from the parent entity, which has its own identity key, to the child and use its :db/id

currentoor21:03:10

so rad generates pathom resolvers

currentoor21:03:49

and i believe pathom requires things to have an identity if you want to have a ref to them

currentoor21:03:50

you could make the :db/id the identity internally, but then you need to have a way to tell the the type of entity and expose the identity key as :entity-type/id rather than :db/id

currentoor21:03:42

or you could treat this referenced entity without a pathom identity as a scalar field on the parent entity (depending on your situation)

currentoor21:03:29

so i could be wrong but that’s my understanding @U0CKQ19AQ or @U066U8JQJ would know more

tony.kay15:03:06

@U09QBCNBY that is really just a marker so it can generate the resolver that goes from that ref to the proper attribute. I don’t know what kind of errors/warnings might be generated, but it really is just used to generate the output clause of a resolver (`{:thing/ref [:thing/id]}`). If you want to hand-roll a resolver that deal with whatever you output there, it’ll be fine.

tony.kay15:03:03

The general intentioin of that marker is “This ref points to one of those things, which can be found using X”

tony.kay15:03:21

then storage adapters or custom resolvers need to fulfill that statement.

tony.kay15:03:22

It does also, I think, generate query joins in the UI, so it does need to be a real attribute name of some sort or things just cannot work…but it never needs to match your real db unless you want it to for convenience and auto-generators.

uwo16:03:17

Thanks so much for the response! While I recognize and appreciate the pattern of flattening card-one, component refs into their parent entities. I'm wondering if in the future we might have a direct way to handle this kind of modeling structure in RAD, as it's quite common in the field to find people who still model with rectangles and rely on parents to locate components. Any thoughts? Also, just so I understand, my path forward is just to create a resolver that takes the parent entity as a param, exposes something like :my.component-entity/id, and returns the :db/id for the component ref?

tony.kay11:03:30

I don’t know what you’re getting at on the flattening vs not. RAD supports both. There’s nothing in the system that restricts you. And yes: at present if you are dead-set on using :db/id instead of a squuid attribute then you will have to write the resolvers yourself. That said, I do plan on supporting that automatically in the future. At present I use UUIDs on all entities because they are stable across dbs etc., so I have no need to use :db/id directly.

tony.kay11:03:46

You’d also have to do something to the save-form for Datomic, since it currently assumes it can use [:thing/id 1] as a lookup ref

uwo15:03:35

:thumbsup: thank you

tony.kay15:03:56

I imagine an option like ::datomic/as-dbid or something on the ID attribute could be used to inform the resolver generator and save function to do so

tony.kay15:03:27

(defattr :person/id :long 
  {::datomic/as-dbid? true
   ...})

uwo16:03:17

Thanks so much for the response! While I recognize and appreciate the pattern of flattening card-one, component refs into their parent entities. I'm wondering if in the future we might have a direct way to handle this kind of modeling structure in RAD, as it's quite common in the field to find people who still model with rectangles and rely on parents to locate components. Any thoughts? Also, just so I understand, my path forward is just to create a resolver that takes the parent entity as a param, exposes something like :my.component-entity/id, and returns the :db/id for the component ref?