Hello. Does fulcro inspect support react native remote debugger? I saw some repo with cljs and clrn macro just to use fulcro inspect on the web while compiling to rn. Is that the only approach? I’m really looking forward to build rn apps with fulcro. Thanks!

hey all, have an issue with parent/child components and their data relationship that I’m trying to work through. a page of mine is querying for a link from the db root (think, active items) and mapping the item data over an item card component. within the item card comp, I have some ui state (e.g. card-expanded?). so my components look something like this contrived example:

(defsc ItemCard [this props]
  {:initial-state (fn [params] {:ui/card-expanded? false})
   :ident         (fn [] [:item-cards/by-id (:item/id props)])
   :query         [:item/id
                   :item/text
                   :ui/card-expanded?
                   {[:current-user/active-project '_] [:project/some-other-unrelated-prop]}]}
  (dom/div #js {:onClick (fn [] (fm/toggle! this :ui/card-expanded?))}))

(def item-card (comp/factory ItemCard))

(defsc ProjectPage [this props]
  {:ident         (fn [] [:pages/by-id :project])
   :initial-state (fn []
                    {:item-card-data (comp/get-initial-state ItemCard)})
   :query         [{[:current-user/active-project '_] [{:project/items [:item/id :item/text]}]}
                   :item-card-data (comp/get-query ItemCard)]}
  (map (fn [item-data]
         (item-card (comp/computed (merge item-data
                                          (:item-card-data props))
                                   {:computed-fn (fn [] ...)})))
      (get-in props [:current-user/active-project :project/items])))

still don’t know what the fix for the above if I wanted to use props is, but I decided to implement the ui bits using react state and the associated fulcro helpers

@mss hello, I suggest you instead use a computed property from the parent to the child. In general any kind of global is bad, and can be avoided, so what I'm suggesting is to have the parent component track the active item, and send that as a computed prop when rendering the list, makes sense?

yeah I guess it just feels a little messy to have a parent manage the local ui state for each child. makes sense tho. thanks for the help!

its a common pattern to do that in this kind of relationships, because its good to have single sources of truth, and in this case having the parent do it instead of a global is a better implementation, because allows you to have many instances of "active" (if you have multiple of the parent class, while if you do a global you can only have one data point for it forever)

yup makes total sense. that aside, is using react state via the helpers discouraged?

I dont know, never tried

all that considered, your issues seems to be related to refresh, you could force a re-render by using :current-project/active-user as a refresh (you can add as a keyword when calling transact!, or in the (refresh ... section of the mutation)

I have trouble using fulcro-garden-css, is there a working sample project that uses it on Github?

how are people handling db entries that need indexing in more than one way? e.g. I have todos and todo lists which each have their idents. let’s assume todos can be shared across todo lists. what if I want to get all the todo lists that contain a given todo ident (i.e. navigate the relationship from child to parent)? if I indexed my todo-lists by todo-id, that’d solve the problem. I can’t quite get a grip on the most ergonomic way to generate that index. three options stood out to me, and I wanted to get some feedback on them: 1) I could maintaining a separate query component just for the second ident. that feels a little wonky since the duplicated query would get forwarded to my remote and expect duplicate data 2) I could do a post-mutation on the initial remote query and generate that index, as well as update it as new data is generated. this feels like an ok middle ground to me between 1 and #3 3) I can just do all the filtering within my component. this is fine, just doesn’t feel very elegant just wondering if there’s a more idiomatic solution that people have come up with beyond those 3

@mss if you data-set is small nothing wrong with filtering you data set in render

otherwise i’d have a top level key in app state called :todo->todo-list it’s value can be a map of todo idents (or ids) to todo-list idents (or ids)

and have a mutation called update-index that scans app state and updates this index, you can call this mutation as needed

which sounds a lot like your #2 idea

awesome, ya that makes sense. appreciate the input

happy to help