Fork me on GitHub
#fulcro
<
2019-09-21
>
vinnyataide07:09:15

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!

currentoor16:09:21

@U17CAUN2F there’s a way to debug RN by running the javascript in a chrome tab on your workstation

currentoor16:09:58

i wonder if the inspector can work there?

wilkerlucio16:09:32

I dont think it works, the current fulcro inspect uses quite specific chrome apis to integrate there. there is an old idea to have a electron version of Fulcro Inspect, that would connect using websockets, this solution could work for RN, or any environment supporting fulcro and websockets, but never got prioritized

vinnyataide17:09:56

That’s what I thought too wilker. Thanks for the explanation

souenzzo12:09:33

@U17CAUN2F I develop a rn fulcro app my workflow/method is: develop fulcro on the web, with a "ugly" dom/div Then go to react-native just to develop a new view I never had the problem of something working on the web and not in the app

mss15:09:56

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])))
on first render, everything seems to be working correctly. if I toggle the click handler that flips that piece of state local to the card, though, the passed-down data disappears out from under the component. all that’s available are the computed props and the card-local data any ideas what might be causing that or how to better implement this pattern?

mss15:09:44

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

wilkerlucio16:09:12

@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?

mss16:09:08

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!

wilkerlucio16:09:51

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)

mss16:09:00

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

wilkerlucio16:09:24

I dont know, never tried

wilkerlucio16:09:28

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)

Vincent Cantin19:09:41

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

mss20:09:03

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

currentoor22:09:56

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

currentoor22:09:33

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)

currentoor22:09:15

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

👍 4
currentoor22:09:29

which sounds a lot like your #2 idea

mss22:09:57

awesome, ya that makes sense. appreciate the input

currentoor23:09:49

happy to help