The default renderer has been changed so that could explain it. It is now the multiple-roots-renderer , which mostly behaves just like the old keyframe-render . Perhaps the older Fulcro version uses the ident-optimized-render , which only renders components with changed data, based on their ident. This has better performance but leads to rendering troubles when Fulcro cannot figure out some dependencies (and does does not re-render something you want it to). For most cases, the multiroot is good enough and simpler.

got it, thanks @holyjak

If you use datomic you can use :company/_primary-account.

Hmm, I just tried that and got nothing... I guess I could just write a resolver for the reverse case

Your pathom resolver has to have a resolver for it.

It needs to be mentioned in ::pc/output and be queried.

I often replace :user/_company in the resolver with :company/user. That gives me readable backlinks in the normalized db.

I am using Fulcro RAD Datomic, no idea if it does create reverse resolvers. Apparently not, because adding :company/_primary-account returned nothing. Hm. While we're at it, do you know if there's a way to make the ::pc/output being "or" instead of "and"? As in, when I give it #{:company/id :vendor/id} to name an example, that i mean either the first or the latter, instead of both

Hmm. Ich glaube Du fragst immer nach beiden und bekommst halt nicht zurück was er nicht findet. Im Output heißt das ja nur, dass er es Dir gibt, nicht, dass er es garantiert.

Das ist ein Set, kein AND.

Also ein Datomic Pull, kein Datomic Query.

Nein, so wie ich das gesehen habe, benutzt Pathom einen Resolver nur dann, wenn es alles, was ins ::pc/input gehört, hat

Interessanter Sprachenwechsel ^^

Jep. In Input schreibst Du Ding/id und im Output Ding/name, Ding/Adresse etc.

🙂

Ding/id muss er kennen. Und dann schaut er ober dir Ding/Name und Ding/Adresse geben kann.

Wenn Du die von Hand schreibst würdest Du ja einen Datomic Pull schreiben.

Genau, aber es gibt wohl keine Möglichkeit, zu sagen, "als Input akzeptiere ich entweder a/id oder b/id"?

Das wären zwei Resolver.

Du kannst aber einen der beiden so klein schreiben, dass er zum anderen führt.

Ansonsten gibt es noch sowas wie "Alias" oder so ähnlich, wenn sich das eine aus dem anderen ableiten läßt.

Hmm okay. Ja, dann gibt's halt mehr als einen 🙂 Danke!

Oder es werden drei Resolver, das gemeinsame in einem und zwei kleine, die zum großen überleiten.

🙂

Ja, ich habe ein paar Attribute, die ich an mehrere verschiedene "Tabellen" anhängen kann, und ich dachte, ich könnte da vielleicht einen Resolver für alle schreiben ^^ Na, ist ja nicht viel Overhead.

Wenn man die Resolver möglichst klein schreibt wiederholt man sich nicht so oft.

Ist Geschmackssache.

here's the code I have so far:

(defsc ProjectDetail
  [this {:project/keys [id name slug] :as props}]
  {:query         (fn [_] [:project/id :project/name :project/slug])
   :route-segment [:project/slug]
   :ident         :project/id
   :will-enter
   (fn [app {:project/keys [slug] :as route-params}]
     ;; we know the slug, but...
     (when slug
       (dr/route-deferred
         ;; we need to put the ident in here and below in the :post-mutation params
         [:project/id ???]
         #(df/load! app [:project/id ???] ProjectDetail
                    {:post-mutation        `dr/target-ready
                     :post-mutation-params {:target [:project/id ???]}}))))}

the closest I've gotten is reading the ID I need directly from the application db:

(when-let [id (->> app
                                         ::app/state-atom
                                         deref
                                         :project/id
                                         (filter (fn [id {:project/keys [other-slug]}] (= slug)))
                                         first
                                         first)]

what if you make the component use :project/slug as the ident?

i'm reluctant to do it because it'd ruin some symmetries, but in the absence of any other approach that might be the way to go

you could potentially have this component be "light" and just be used to translate from slug to id and then have it render a component that uses project/id

hm, interesting idea--so this wrapper would have :project/slug as its ident. but then that would require a separate :project/slug table with a join onto the :project/id table, right?

(btw your template's awesome, i'm using it on this project 🙂 )

yea i'm thinking you'd have two tables one indexed by slug and one by id

woot! glad to hear it!