fulcro 2022-01-05 | Slack Archive

tony.kay04:01:08

@mithrandir03 https://github.com/fulcrologic/deep-tree-optimization-demo This is a working demo that auto-generates a large tree of nodes, and uses a combination of fixed depth and infinite depth queries, react hooks, and sync transactions to make the whole mess fast. On my machine I can create a tree of depth 6 with a branching factor of 5 (node has 5 children that themselves have 5 children, etc)...so about 17k nodes. Interacting with this tree is very fast and slows down as you open more and more nodes. BUT, you have to open a LOT of nodes before there is any kind of problem. <Http://localhost:8080/index.html|Http://localhost:8080/index.html> with build running is how to try it.

❤️ 4

bmaddy20:01:31

I need to toggle the visibility of some fields based on some checkboxes in a parent form. I believe I need to pass the values down using comp/computed. Is there a way to do this in RAD or do I need to re-implement the form in plain fulcro?

bmaddy20:01:21

Ah, I might have found it: https://book.fulcrologic.com/RAD.html#_subforms Hopefully I can use that with fo/fields-visible?.

bmaddy21:01:05

Oh, now that I look closer, that's the "use plain fulcro" route since the parent is a normal fulcro component.

zeitstein22:01:30

Playing with Fulcro Raw. In the below I'm defining a component, using `merge-component!` to get some initial state, then I use `initial-params` to add a component with a specific ident.

(def Node (rc/nc [:id :text :children]
                    {:initial-state (fn [init] init)}))

  (merge/merge-component! app Node
                          [{:id 1 :text "1" :children [:id 2]}
                           {:id 2 :text "2"}])

  (rapp/add-component! app Node {:initialize? true
                                  :keep-existing? true
                                  :initial-params {:id 1}
                                  :receive-props (fn [props] (println props))})

It doesn't work without `initial-state` on `Node`. Wondering whether this could be simplified by allowing `add-component!` to simply 'point' to an ident (in db) directly?

zeitstein22:01:37

Basically wondering whether something like the following would be nice to have:

(def Node (rc/nc [:id :text :children]))

  (merge/merge-component! app Node
                          [{:id 1 :text "1" :children [:id 2]}
                           {:id 2 :text "2"}])

  (rapp/add-component! app Node {:ident [:id 1]
                                 :receive-props (fn [props] (println props))})

tony.kay00:01:36

possibly? Don't remember what's there. I'm game to expand it as needed

zeitstein08:01:59

My "nice to have" example actually works, sorry. Though, if not explicitly passed :initialize? false, calling add-component! will produce an entity nil {} in app state. I think this is because maybe-merge-new-component! has initialize? true as default. I'd consider doing these slight modifications (possibly at several places in the raw/hooks API): • Explicitly set the default value of initialize? to false in add-component! (and the like). • Explicitly state in the docstring that :ident is a valid key in the options map of add-component!. Like in use-component :) > * :ident - Only needed if you are NOT initializing state, AND the component has a dynamic ident. Though, I do think I may be missing why the API is as it is.

tony.kay17:01:56

changing defaults on a released API isn't an option, but updating docstrings is fine. I have not looked at the details on those in a while, as I have a lot going on and don't use those facilities much. For me they are like a spice you need on occasion. I do have a desire to leverage the hooks support, RAD, and the new statecharts in experiments to see what we can come up with, but don't have time right now

2022-01-05

Channels