Fork me on GitHub

I am getting this warning log when a component unmounts that doesnt have an ident nor props:

WARN [com.fulcrologic.fulcro.components:494] - get-ident was invoked on  atlas-crm-kit.ui.components.button/ButtonGroup  with nil props (this could mean it wasn't yet mounted):  
Is that expected behaviour?


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)}
   (when (comp/get-state this ::show?)
   (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


Is there a best practice for dealing with components that are siblings (shared parent) and 2 different queries on the same data? Specifically, I need to join on the same edge in the parent in a query. Additionally, I would like to avoid breaking my query composition or introducing extra layers of dom and indirection if possible. I have an edge at the root that needs to join via a link query to both, similar to this query fragment below, though maybe this approach is wrong from the start:

;ui/active-workspace is created via a targeted load! and contains an ident that links to :workspace/id - a list of workspaces by id

;WorkSpaceStatus has an ident of :workspace/id and pulls a few fields
{[:ui/active-workspace '_] (comp/get-query WorkspaceStatus)}
;WorkspaceDetails has an ident of :workspace/id and pulls a few of the same fields, but mostly different fields
{[:ui/active-workspace '_] (comp/get-query WorkspaceDetails)}
I thought of one simple workaround which was to nest each a level deeper with a respective pass through component (2 more components) that each do a link query that joins to the appropriate component. I would use initial state to create placeholder edges for both components of course. I think this will work, however I feel like there must be a simpler way, perhaps with unions or a different approach entirely. The biggest complication is that they aren't rendered one after the other in the parent, which to be fair, makes a case for the workaround approach.


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


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


I'm getting a bit stuck with resolving tempids. Am i missing any steps? 1. Create new item in ui, new tempid is create and used in mutation. 2. Server returns {:tempids {the-client-sent-id server-id}} (at this point the client db is still showing the tempids) 3. Send a delete mutation of our item -> the tempid, not the real id is being sent to the server. Everything is working fine after a page refresh. (real id's are sent in the delete mutations) I'm using a minimal client side mutation, only setting (remote [_] true) Using fulcro 3.0.4