@tony.kay where was your book again?

found it http://book.fulcrologic.com/

is there a way to :target a load to have the return data merged into the root of the state db, as opposed to underneath the load key/some specified target key?

@mss I don't understand. That is the default mode of load

state is a map. You have to put things in there with a key

yep get that. let’s say my call to load for :user with a query of [:user/email :user/first-name] receives back a map like {:user/email "" :user/first-name "andy"}. when fulcro merges that load back into the state map it’ll look like {:user {:user/email "" :user/first-name "andy"}}. makes it slightly annoying to join throughout components, as I’m constantly doing [{[:user '_] [:user/email :user/first-name]}]. the alternative – and this is the crux of my question, I just don’t know how to accomplish it – is to merge all the properties returned by the :user load into the root of the state tree, so there’d be :user/email and :user/first-name keys at the root of the state tree, as opposed to nested under the :user key. that’d make querying for that returned data much easier, especially when its nested maps of properties (e.g. a user’s team member’s likes)

just spitballing. I don’t know if that’s recommended or even a good idea

See the new docs on shared-fn

http://book.fulcrologic.com/#SharedState

a shared-fn of select-keys would be good for this

you just need to make sure that a top-level refresh happens if such shared data changes...and in this case that's easy, so it's a very good fit.

That support has been in Om Next and Fulcro since very early (2015), but not well-documented.

note that shared-fn is on root props not the state database. Therefore anything you want to share from root has to be queried at root.

nice, really appreciate the help

welcome

hey @tony.kay what should I do if I find a typo in the book? is there a way to submit a pull request?

@currentoor https://github.com/fulcrologic/fulcro/tree/book

@wilkerlucio thanks, i didn’t realize it was in the main app

no problem 🙂

I was bumping our app to 2.1. We had a homegrown routing component but I wanted to use the official Fulcro router. I got this example from the book working in my app http://book.fulcrologic.com/#_a_complete_ui_routing_example But for some reason switching to a new route (via clicking the links) does a double render. - First render from root is called with the current route - Second render from root is called with the new route This doesn’t seem like the way it should be, any ideas what could be wrong?

Also, was mutation logging turned off intentionally? I don’t see it anymore.

Clicking on current tab causes a single re-render too, that seems very strange.

@wilkerlucio @currentoor it is all on mainline development now (the book)

The source is DevelopersGuide.adoc in the root of fulcro

the book branch is no longer used. I should delete it

ah i see

ups, sorry, I just saw the branch there and assume was been used

@currentoor doing a transact will always render...what is your issue in particular?

also, in the context of the book, I'm embedded an app in an app

so there may be spurious rendering that is related to that

I added your example from the book into my AdStage app, and switching to a new route causes render to be called twice (once with the old route value and once with the new value)

I added that example into the root component of my app, should switching to a new route cause render to be called twice?

i guess i can verify with the example application

i just assumed that was not correct behavior

ok, so it is possible there is a double call of render...but if the logic makes it into render, then some data changed

there are two primary ways render gets queued: transact will queue things up, and swap!s on the state atom queue a root render/reconcile.

scheduling a render does happen on an animation frame rate (throttled to 60fps), so a combo of transacts and swaps could trigger a dual render pretty easily.

oh so maybe this isn’t a problem then

does it cause usability issues?

nope

so a single transact and the swap!s inside it can trigger separate renders?

so, it might be non-optimal. The rendering code rewrite was pretty invasive in 2.x. The fact that you're seeing old state then new is strange.

the routing stuff is more complicated than that due to code splitting support.

I'd have to look at the code to come up with explanations

knowing what changed on the first render, compared to what changed on the second would be helpful

i’m just worried this will get expensive when i have a bunch of charts already rendered on the screen

your render body will not execute unless something actually changed. So, double-render should not happen unless there is a data change.

so, figuring out what changed in each of those steps is key to knowing why

state1 (no routing) -> state2 (clicked for new route) -> state3 (route took effect)

ah...right

i think only the diff is in that screenshot 😅

i should have circled it or something

so, one diff should be one render no matter what

do something else before routing to get a better tx history

> so, one diff should be one render no matter what then it might be something i’m setting up incorrectly, perhaps i should verify that this happens in the example application?

shouldComponentUpdate returns false if the data hasn't changed. Where is your print?

did you accidentally include it in more than one place?

the print is inside the render body of the root component

did not include more than once

ah, that's a clue. force-root-render! is an exception: it forces the UI to update everything

I don't think I force a root render in routing, but I'd have to look.

which routing instruction are you using?

#(prim/transact! this `[(r/route-to {:handler :main})])

is that what you mean? i just copied the example from the book exactly

yes

so, as far as I can tell there should not be a double-render there

Ah, there is a case where this can happen

the new optimal render path has to do a forced update of a given component in case it was just a component-local state change. This would cause you to see the old props, then the new in rapid succession.

The forced update only affects the component, as all child shouldComponentUpdate calls will return normally so that children won't render.

just verified and you’re right!

only the root component render body was being called, not it’s children

At the moment, anything that is targeted at root will cause a double-root node render

but should be cheap

right

The new optimizations only work on components with idents. Root doesn't have an ident.

i see

thanks for the help and explanation

but shouldComponentUpdate is a pretty major optimization

and the forced update does not re-run the query, which is the expensive part

I haven't started recommending it, but using a placeholder root that does nothing but delegate to a node with an ident has a couple of benefits. One would be that it will be so lightweight that this could never matter; however, the other advantage is that nothing ends up in the root node but a single keyword (like :ROOT) and your tables.

can’t that be done by Fulcro?

It could, but it would not be bw compatible

i see

since it would move things that you might be using link queries for

and that is a main disadvantage...since nothing is in the root node, [ [:rootprop '_] ] is less useful

so, I'm still on the fence about it being a "good idea"

I like it, in that it makes it easier to find the stuff you're considering to be your root, since it is all in a map keyed at :ROOT

however, as I pointed out to someone earlier today: shared-fn can be used to pull info out of the root props and into shared. That doesn't get broken...you just have to walk the props into :ROOT before pulling data into shared.

> since it would move things that you might be using link queries for if you’re using link queries, it shouldn’t matter if data moves up one more level right?

ident-based queries, no...but root node is not longer root node, so it would make it harder

you could no longer just pull an arbitrary root node value...you'd have to pull everything in :ROOT and then deal with that...and you would never want to join that with the actual root query, or you'd make a big mess

so you wouldn't get denormalization without then writing some other component to query against the fake root

[ {[:ROOT '_] (prim/get-query FakeComponentForPropINeed)}]

[ [:ROOT '_] ] would just give you the ident of the new offset root node

I see, well I haven’t seen any super complicated roots. Feels natural to write simple roots that delegate to other more complicated components.

but I do have a smallish sample size 😅

I'm tempted to make a "she said" joke there... 😜

😏

careful now, don’t want fulcro to be crucified on twitter…

any press is good press these days it seems

well we already know fulcro is so offensively good that it might cause someone to piss all over your expensive mechanical keyboard

I don't think that is actually common knowledge

maybe it should go on the website

urination stories probably aren't the best fit there 😉

lol

for anyone lurking on this convo...^^^ is a true story

@currentoor I have this helper function that I like to use to make roots:

(defn make-root [Root app-id]
  (fp/ui
    static fp/InitialAppState
    (initial-state [_ {::keys [root-state] :as params}]
      (merge
        {:fulcro.inspect.core/app-id app-id
         :ui/root                    (or (fp/get-initial-state Root (dissoc params ::root-state))
                                         {})}
        root-state))

    static fp/IQuery
    (query [_] [{:ui/root (fp/get-query Root)}])

    static css/CSS
    (local-rules [_] [])
    (include-children [_] [Root])

    Object
    (render [this]
      (let [{:ui/keys [root]} (fp/props this)
            factory (fp/factory Root)]
        (factory root)))))

I think we talked about that one before @tony.kay, but I think we agreed it's not generic enough for general case, maybe

And @wilkerlucio saves the conversation 🙂

react-key isn't needed anymore

cool thanks @wilkerlucio

well noted, I just bumped this project to fulcro 2.1 today 🙂

2.1.1?

yeah, also, the root div can also be removed

there's a bug in union stuff that was just fixed

snippet updated