not enough detail about your program to know….but on UNmount???

Could be a mistake in rendering code trying to render something that left the screen.

In this example below I mount/unmount a loading-state component by pressing a button. I get the warning log when the component unmounts.

(defsc LoadingState [this props]
  (dom/div "Loading..."))

(def ui-loading-state (comp/factory LoadingState))

(defsc Initializing [this _]
  {:query [::key]
   :initial-state (fn [_] {::key ::init})
   :ident [:init ::key]
   :route-segment ["init"]
   :route-cancelled (fn [_])
   :will-enter (fn [_ _] (dr/route-immediate [:init ::init]))
   :will-leave (fn [_] true)}
  (dom/div
   (when (comp/get-state this ::show?)
     (ui-loading-state))
   (button/ui-button {::button/on-click #(comp/update-state! this update ::show? not)
                      ::button/label "Toggle"})))

it looks like a spurious warning on a optimized refresh to a component that is no longer mounted…annoying, but harmless

prob just need a mounted check in the optimized render code

Make 2 edges in the same parent

both will point to same table in db…nothing surprising…if you need an edge, make an edge…but no, you can’t “share” an edge

OK, thanks for your time

on the link query: I take it the workspace status is some kind of singleton?

it has no ID and is shared among several components

I’m not sure I understand that question

It sounds like you have a top-level edge that points to a normalized entity that is a list of other (normalized) entities. You can access that from anywhere via the link query you show…that’s all true….not sure what your actual problem is

link queries don’t need other literal edges in the graph

{:ui/active-workspace [:workspace/id 1]
 :workspace/id { 1 { ...} }}

I see where he’s getting confused - two link queries in the same component on the same table, both pointing to :ui/active-workspace. In your props, you would end up with 2 maps keyed on :ui/active-workspace. Not sure how/if Fulcro handles that - if it detects it, you could merge the maps together, otherwise one probably overwrites the other. But it seems to me the best solution is to move the link queries to the child components so you can invent an edge for each one in the parent.

OH, I didn’t see the two diff components…I though this was in two diff locations…OK, I see.

The sol’n is to make one component that does the full query, and use logic in the rendering code (possibly pass computed prop as a flag) to have the thing render what you want in a particular situation

@U5YA41N3G

e.g. (ui-workspace-detail (computed detail-props {:mode :a}))

then in render (case mode :a …), etc/

hey sorry, busy day. Anyway, yeah it's as mdhaney said, 2 components.

Definitely the 1 component solution is more what I was hoping for, as my workaround was the 2 component solution mdhaney mentioned. I will give it a try and if I have any problems, I guess I'll report back but that makes sense I think.

For clarity in case someone else is wondering, yes the data is being loaded and normalized, where the table is :workspace/id and the target is :ui/active-workspace that has the ident of the workspace loaded.

also, side note, see computed-factory, which makes passing the computed stuff more convenient