“definitive” is a strong word for free open source. I strive to make all documentation as correct and complete as possible. If it is mentioned anywhere and works, then it is as official as it gets.

So, there is a ton of variability in the question. Bootstrap is CSS, and it also has non-react js components. There is not a great way to use the js components (though I wrote some wrappers for the css at one point if you look in F2 source or earlier…abandoned, but semi-working). You are more likely asking about how to do form state and interaction, which has nothing to do with bootstrap. The book goes into quite a bit of detail on using Form State helpers. In your example below you seem to want a modal, which is whole other thing that has nothing in itself to do with forms other than they sometimes “hold” forms.

did you destructure them and pass them through??? There is nothing magic about the props…they are a tree passed from root

I'm routing to the main sub component that have initial-state, so it acts like root (?) in that context, maybe because of that??

I cannot possibly answer your question any better without seeing code.

You have a point, I tried to shrink code to it's basic.

;; router 
(dr/defrouter ProjectPanelRouter [this props]
  {:router-targets [ActionList]} )
;; where we route to our component with initial state
(defsc ProjectPanel [this {:project-panel/keys [router] :as props}]
  {:query           [{ :project-panel/router (comp/get-query ProjectPanelRouter) } ]
   :ident   (fn [] [:component/id :project-panel])
   :initial-state {:project-panel/router {}}
   :route-segment   ["project-panel"]

   (dom/div
    (ui-button {:onClick #(dr/change-route this (dr/path-to  ActionList {:action-list/id  (random-uuid)} ))})
    (ui-project-panel-router router))})
;; the target route (with init state)
(defsc ActionList [this {:action-list/keys [id actions] :as props}]
  {:query [:action-list/id {:action-list/actions (comp/get-query ActionRow)}]
   
   :route-segment   ["action-list" :action-list/id]
   :ident  :action-list/id
   :initial-state (fn [params] {:action-list/id (random-uuid)
                                :action-list/actions [(comp/get-initial-state ActionRow {:owner "Owner" :action "Action" :id 1})
                                                      (comp/get-initial-state ActionRow {:owner "Owner2" :action "Action2" :id 2})]})
                                        ;:initial-state {:project/id 1 }
   }
  (map ui-action actions))


;; child component 
(defsc ActionRow [this {:action/keys [action owner status due-date] :as props}]
  {:query [:db/id :action/action :action/owner :action/status :action/due-date]
   :ident [:action/id :db/id]
   :initial-state (fn [{:keys [owner action id]}] {:action/owner owner :action/action action :db/id id})}
  (dom/ul
   (dom/li {} action)
   (dom/li {} owner)))

I have noticed when having ident that depends on props, it doesn't work (props don't get passed from init state), having an ident which doesn't use props did the trick (ActionList comp) but still don't get it, why can't props that come through init state can't be used in the ident.

so, props do get passed from init state, and the ident function really must use the data that is passed in props or they cannot work. I don’t understand that statement. OH, I think you misunderstand the diff between initial state as a lambda and as a map.

as a map, it is magic.

The equiv initial state in ActionList is:

:initial-state {:action-list/id (random-uuid)
                :action-list/actions [{:owner "Owner" ...} { :owner "Owner2" ...}]}

perhaps that was your problem? I’m pretty sure there is a misunderstanding in there somewhere, but the code as you show it above looks fine as far as I can tell.

Why aren’t you just using the goog History API?

or are you not using the URL to track history? You’re suggestion has merit in some circumstance.

Thank you! So I guess what is happening in practice, for the first target, is something like (pseudocode):

((factory MyFirstTarget) (merge computed-props (:alt0 props)))

If you just follow that link and read the macro code, you can quickly see exactly what it is doing…computed is carried as a special prop if it is to one (a map) and as metadata if to-many….but in either case Fulcro knows that the data was computed and can re-supply it on targeted refresh.

I would dispute the "can quickly see" part 😅 I have studied the code yesterday (before asking) but failed to grok it fully. Thank you!

agreed 😄 if you’ve read and understood the reason for computed, that is, then it is a single line of code in the macro that I linked you to, which is just ferrying computed.

Yeah, I read the line but lacked too much background knowledge to understand it.

I read about computed properties in the book but still...