(defrouter MainRouter [_this {:keys [current-state route-factory route-props]}]
  {:always-render-body? true
   :router-targets
   [MyReport]}
  (div
   (dom/pre {:data-start 99}
            (dom/code :.language-clojure
                      "(defn "
                      (dom/mark "bar")
                      " [x] (println x))")))

If I change the (if ready? to just (if true the rendering always just works 😕

(defrouter TemplateMainRouter [this {:keys [current-state route-factory route-props]}]
  {:always-render-body? true
   :router-targets      [LandingPage]}
  ;; Normal Fulcro code to show a loader on slow route change (assuming Semantic UI here, should
  ;; be generalized for RAD so UI-specific code isn't necessary)
  (ui-foo)
  #_
  (dom/div
    (dom/div :.ui.loader {:classes [(when-not (= :routed current-state) "active")]})
    (when route-factory
      (route-factory route-props))))

(def ui-template-main-router (comp/factory TemplateMainRouter))

(defsc Root [this {:ui/keys [ready? router]
                   ::app/keys [active-remotes]}]
  {:query [:ui/ready?
           {:ui/router (comp/get-query TemplateMainRouter)}
           ; [::uism/asm-id ::MainRouter]
           ::app/active-remotes]
   :initial-state {:ui/ready? false
                   :ui/router {}}}
  (if #_ ready? true ; always works
    (div
      (ui-template-main-router router))
    (div :.ui.active.dimmer
      (div :.ui.large.text.loader "Loading")))

I guess the route target is not yet routed to and thus rendered when prism runs. It would help if prism had some api tu run it manually so you could delay that.

@U0522TWDA thanks very much for the hint! Indeed, there is an API for that and it looks like it works from my first REPL test. What would be the right place to call the highlighting function? I'm guessing inside :componentDidMount.

That sounds right

db->tree has a weird signature. The args are: 1. the query for the starting entity 2. the starting entity itself 3. The state map You’re passing it: 1. The query for an entity 2. a vector of data (joins are the only place to-many are expected, and your query and tree are NOT a join) 3. Nothing You would need a root node with a join to get this into proper shape

And you would actually use tree->db to make the db, and then you can reverse the process with db->tree

I think I show this is some of the grokking Fulcro videos? And in various other places.

I got it from the tutorial:

Anyway, I was just trying to illustrate that the query of my list component is actually not getting anything. I'm being passed nil props.

99% of “getting Fulcro” is query+ident+initial state. If you show the actual code you’re using, I can point out your error. But it is really really simple (most ppl make it WAY harder than it actually is): 1. component queries are composed into a big huge graph (component queries do NOT live in isolation) 2. Initial state HAS to exactly match the shape of (1) so that it can be normalized (via the ident function and tree->db) into a graph db that has the EXACT structure to fulfill (1) via db->tree 3. Fulcro runs the query (from root) against the graph. On the surface this seems a bit crazy. You literally use a mirrored tree of data and a graph query to create the db, then pull the original tree back out to feed to the UI. The whole purpose, though, is to get it normalized. IF you’re thinking that a component query should “just work” in any context by some magic, then you will be confused. That is not how it works.,

Yes, it was working until I introduced this list component, which query fragment I understood was to be a vector of keywords. Am I right in understanding that such a query fragment should work? Trying again, I will post the code if I fail again.

How can I check that the compound query against the compound initial-state?

I am seeing that the props of a component must always be a map, so one can't define a component that admits a list as its state, right?

The initial state of a component should always be a map, correct. When you want to do a to-many, that should be represented in the intitial state of a component at the join (in your case at the root).

the basic check is: (get-query Root) is compatible with (get-initial-state Root {})

so, the query of a list of things might be [{:things (comp/get-query Thing)}], and the initial state could EITHER be a to-one or to-many relation…the query doesn’t determine that, your data does: :initial-state {:things {:id :a}} is one, and :initial-state {:things [{:id :a} {:id :b}]} is many

of course if you’re doing proper composition then the nested items should be calls to get-initial-state, but if you look in the docs around initial state, you’ll see that the non-function version of initial-state is “magic” and does that for you based on query analysis

I must run the docs sample again. I'm introducing idents to my own component hierarchy, but I don't see my initial-state being normalized.

Thanks for your help. Appreciate the time.

This short demo might help you troubleshoot such problems https://m.youtube.com/watch?v=rzK0_k5lzg4&list=PLYvJiiE4TAijBAvO-R0PO8plSto4wtoQu&index=4

Hey Gene. So forms can have default values for form fields, but by default don’t have “initial state” beyond that. The easiest way to do what you want is to augment the state machine for the form. Add an alias for your new prop, include the prop in the query inclusions, and the add it to the proper handlers in various spots in the state machine. Here’s a helper function:

(defn augment-event
  "Add `additional-action` to the end of the actions performed by the `base-machine` in `state` for `event`. `event` can
  be nil if there is just a global handler for that state. Returns the modified machine, so more than one of these
  can be threaded together to modify a machine in multiple places."
  [base-machine state event additional-action]
  (let [handler-path     (if event
                           [::uism/states state ::uism/events event ::uism/handler]
                           [::uism/states state ::uism/handler])
        original-handler (get-in base-machine handler-path)]
    (assoc-in base-machine handler-path (fn [env]
                                          (-> env
                                            (original-handler)
                                            (additional-action))))))

Then set the form to use your new state machine with fo/machine

E.g.:

(uism/defstatemachine custom-form-machine
  (-> form/form-machine
    (update ::uism/aliases assoc :show-cloud? [:actor/form :ui/show-word-cloud?)
    (augment-event :state/loading :event/loaded some-uism-env-function)
    (augment-event :state/saving :event/saved some-uism-env-function)))

Just look at the existing state machine to figure out where you’d want to augment

Your env function can then use your new alias:

(defn new-env-f [env]
  (uism/assoc-aliases env :show-cloud? true))

Thank you, @tony.kay! I’ll study this, and keep you posted. 1. Does it change the answer if I meant to say this was for a RAD Report, not a RAD Form? (I suspect no, since this is all done thru state machines.) 2. I just knew you were going to suggest using state machines to do this. 🙂

Same answer for both

The lifecycle of the data in RAD is always controlled by the state machines. The exception with reports is that you could declare your thing as a control, in which case you can give that an initial value, which can be overridden by incoming route params

As a control! Yes! That's what I should actually do. Thanks!!!!

I am sure I am going to quote you saying this somewhere :-)

yes, see https://book.fulcrologic.com/#_creating_components_just_for_their_queries

https://blog.jakubholy.net/2020/fulcro-divergent-ui-data/ is a good resource as well for cases like this.

There is also the new helper in raw.components: nc , which returns a component with an unnamed and unregistered component with a query and ident. It’s a little more terse, but useful if you use the preferred naming conventions: (def X (rc/nc [:thing/id :thing/name])) is the same as (defsc X [_ _] {:query [:thing/id :thing/name] :ident :thing/id})

be careful not to use those mixed in with UI concerns unless you give them a :componentName option, since they have to be registered to work properly everywhere…but standalone for just loading or something they are fine.

FYI https://fulcro-community.github.io/guides/tutorial-advanced-minimalist-fulcro/index.html#_what_to_do_when_ui_components_and_data_entities_do_not_match_11 has a summary of the article @UPWHQK562 posted

Thank you for the info and resources!

Fulcro’s DOM nses with shadow-cljs and npm packages works flawlessly, and is what is officially supported. I use advanced compilation with all of my projects and have never had a problem.

The DOM stuff is super-optimized and uses a lot of low-level js stuff to get the best possible performance. I would love to know if you find an issue that the stock compiler cannot handle, but if you look at the Fulcro DOM namespaces you’ll see that there are not many calls to the low-level react stuff.

Try compiling with advanced with source maps. That might help you pinpoint problems.

Thank you for letting me know about source maps. I learned more with source maps but I'm not sure what is causing the error. All is well until an input element is rendered. Fulcro dom's wrap-form-element contains

{:onChange (goog/bind (gobj/get this "onChange") this)}

{onChange:$goog$bind$$($goog$object$get$$(this, "onChange"), this)}

I am going to try shadow-cljs and see how long it takes to setup.

Shadow was easy to setup and advanced compile worked right away.

When in doubt go with the supported configuration 😄