so what is the best way to debug "render" problems? I have a bunch of messages streaming in from a websocket and often re-renders seem to miss. meaning that all the state is updated properly but the UI doesn't update. I can hit the render button in fulcro-inspect and it'll update the UI properly. as far as I can tell I'm telling the UI what to refresh via (fc/transact! app [] {:refresh vec-of-idents}) which I assumed would queue an actual render by maybe doesn't?

@thheller Re-render should be done with the functions in the application ns, not as an empty tx. Also, you say you have messages streaming in…how are you integrating that state into the app itself?

swapping directly into the atom

too annoying to make a tx for everything 😛

so, you don’t need normalization? Just hacking it into place?

yeah not needed. all flat values

then it is likely you’re not getting optimal refresh, but the answer remains the same: app ns refresh functions…schedule-render is recommended. You might switch to the keyframe renderer if you’re not using ident-based normalization

I added some logging and whenever I queue the refresh it does actually render afterwards

no need to take the analysis overhead if you’re just going to end up with a root render anyhow

just somehow not with the data I swapped in before calling refresh

I know exactly which ident I changed (most of the time it is just one)

if I trigger a full app refresh for every single websocket message the whole thing never catches up

schedule-render! should be a no-op if something is already scheduled

it frame limits at 60fps using RAF

and while scheduled it should ignore addl requests

so, you do have normalized data…it’s just your messages are hitting known things that have no nested state…I think I misunderstood earlier

oh yeah sorry. the data is normalized. I mostly just (swap! state update-in [::some id ::foo] merge some-data)

or just (swap! state assoc-in [::some id ::foo] new-val)

right, and have you tried schedule-render! ?

no, I thought it doesn't watch the state-atom and won't know what changed?

thats why I went for the fc/transact!?

watch on the state atom has nothing to do with it

I must avoid a full re-render

too slow.

tried that.

So, tried what?

specifically

what do you consider a full re-render

not using the ident-optimized render and just re-render everything

but what function were you calling?

keyframe-render/render! something

set as :render! in opts

ok, so, don’t override anything, and use schdule-render!

so no fc/transact! just schedule?

there is never a watch on the state aom

correct

the default render does an optimized diff on state based on on-screen components’ idents

same problem

what? never catches up?

no, it somehow misses an update. If I press "re-render" in fulcro-inspect everything is fine

ok, so re-render in inspect forces a refresh with no optimizations

your problem is almost certainly that you are rendering something that is not represented in the component query

refresh optimizations use the queries in the state diff

hmm is this maybe the problem?

:query
   (fn []
     [::rid
      {::runtime [::runtime-info
                  ::supported-ops]}
      {::objects (fc/get-query ObjectListItem)}
      {::object (fc/get-query ObjectDetail)}
      ::nav-stack])}

http://book.fulcrologic.com/fulcro3/#_ui_refresh

::supported-ops not properly updating is one of the issues

let me think….I don’t know how the indexer would respond to that

The conversion to AST would be missing a component (and ident)…but there is nothing that would mount there (supported ops is rendered in that component I assume)

In general if you have a non-normalized chunk of opaque data you don’t represent it in the query (since it will just be extra db->tree overhead)

hmm let me try just adding a component with ident for this. maybe that fixes it

do you have a natural ident for it?

:query
   (fn []
     [::rid
      {::runtime (fc/get-query Runtime)}
      {::objects (fc/get-query ObjectListItem)}
      {::object (fc/get-query ObjectDetail)}
      ::nav-stack])}

I would personally just drop the join

doesn't fix it

[::rid ::runtime …]

but wait…you did that really quickly…Runtime is already a component?

(defsc Runtime [this {::keys [rid] :as props}]
  {:ident
   (fn []
     [::rid rid])

   :query
   (fn []
     [::rid
      ::runtime-info
      ::supported-ops])}

  (html/div "runtime" (pr-str props)))

(def ui-runtime (fc/factory Runtime {:keyfn ::rid}))

not used anymore but was still in the code. just adjusted the query

and you changed render to render with its factory?

no. I need to look at the ::supported-ops to decide what to render

that’s why you don’t get refresh

defsc hacks into componentDidMount to index components that are on-screen

if you don’t actually mount a component there, then nothing ends up in index

hmm thats why I didn't join 😛

but yeah that makes sense

so, don’t normalize either

how do I get the data then?

I’m saying that the runtime stuff can just be an opaque map at the ::runtime key on that parent

I have a "page" which has {::runtime [::rid 123]} (in the data)

as an ident

that has to be done as a component for refresh

BUT, you can just put a map there, and don’t write a join

that entire value will then show up in the component

I don't follow. the data must remain on the runtime itself?

OK, so the diff on the parent checks to see if the IDENT of the child changed. It is expecting the child itself to manage its own refresh…parent (when normalized) only cares if the identity of the child changed

If you make the child a “scalar” (not a join in the query), then the parent will care about the value (which in your case would be a nested map in app state)

But of course you lose normalization convenience if you do that

so if you need normalization, then we need to talk about how to fix your overall approach

how do I query ... I just don't follow because I don't know how to query a value from another ident without a join

the point is it would NOT be an ident

I have a runtime-page and a runtime

it would be a map

ok, so you’re indicating that you need normalization

runtime-page has {::runtime [::rid 123]}

and a bunch of relevant stuff for the page itself

and the data in [::rid 123] is used in many places on screen or in db?

::rid is runtime-id

yes

ok, then the answer is “yes, you need normalization”…in that case you also need to use proper join query and component factories

ok so instead of runtime-page working with the data directly I need to pull those parts out

got it

right, and I suspect you might have logic that would benefit from a union query…but just guessing

nah probably just lazy. its an overview page showing some stuff about the runtime and then all the other data it reads

ok, cool

didn't want an extra component for a div basically

but yeah makes sense that it doesn't update properly then

There are other options…the runtime has a spot to put “additional refreshes” for the scheduled render…adding the ident of the parent there should do the trick. That’s essentially what you were trying to do with your transact! trick..but I think an empty tx just ends up being a no-op. No queue processing happens, so nothing gets scheduled.

you could try adding options to schedule-render!…I think that would work: (app/schedule-render! app {:refresh [ident-of-parent]})

There is also an :only-refresh option

both of those options only work with the default renderer, and I’ve not tested the latter heavily…but I see no reason why that would not work. Sounds like you’re possibly a good use-case for the :only-refresh…it circumvents the diff analysis and just schedules a targeted refresh.

ok one problem seems to be fixed. can't reproduce anymore

should now the able to fix the other too

thanks!

I should have documented that those options on transact! are passed through to schedule-render! Welcome 🙂

I'll try those options

Just to be clear, @thheller, :refresh means “do the full refresh analysis, and include this extra stuff even if it doesn’t look dirty”, and :only-refresh completely skips the state diff, so is faster when you know what you want to refresh.

Both support keywords (which looks up idents via query index) and idents.

:only-refresh is likely what I want then

yep

For reference, here is the logic: https://github.com/fulcrologic/fulcro/blob/develop/src/main/com/fulcrologic/fulcro/rendering/ident_optimized_render.cljc#L100

Oh, and in the case where you’re not using a factory for that child, the ident/keyword you want to refresh is the one on the parent.

(i.e. :only-refresh [::runtime])

@tony.kay one more thing. I have split up the representation of one ident into 3 smaller ones. basically because the body changes a lot while header/footer don't. premature optimization I know ...

(when object
        (html/fragment
          (ui-object-header object)
          (ui-object-detail object)
          (ui-object-footer object)))

but now I can't figure out how to make one "object" component that then does the split?

or maybe its just something else but sometimes this display doesn't update either. although those components always have [::oid 123] as their ident

I'll probably jujst make 3 regular react components to do the split

no point it doing it this way

so, if they share an ident, the renderer will trigger refresh on them all anyway when the data changes…if their queries differ, then s.c.update might actually short-circuit

I would make one component, and you could push the header/footer out to comps without a query/ident just to get the s.c.u. optimization

(defsc Header [this props] (dom/h4 ...)) (no options at all)

There’s no reason a Fulcro-compatible backend couldn’t be written in CLJS, right?

yes, completely agnostic, Pathom already works in CLJS. You could have a ‘server’ locally in your browser right next to the client (this is what the Fulcro book does)

Nice! Very happy to hear. Thanks