Hi there, I just want to prototype something on the front-end only. Is that easy to do with fulcro?

In F3 I'm doing a load from a button. As a parameter I'm passing a tree of data. i.e. reaching in to other components. This tree is not up to date with the state that I can see in Fulcro Inspect. I can make this tree up to date by pressing a different button that does a mutation that presumably refreshes these 'other component instances'. I can think of ways to try to work around this. But ideally I'd like to 'make sure this tree is refreshed in the UI' before doing the load.

Ah, interesting scenario @cjmurphy. The new optimized render does, in fact, no longer patch the props tree like F2 did. You can switch to the keyframe renderer, and it will behave correctly for that scenario.

well, also: Make sure you force refresh the parent, just like you would in F2. So, when whatever mutation is modifying the child in question, it should queue a refresh for the parent. I did add :refresh options to support that….so, in fact, it is still workable with the ident-optimized render. I was just hoping that ppl would not need to think about it.

I’ve not had time to performance compare the two renderers, but I do expect that the overall overhead is significantly reduced so that the keyframe render should be fast in most cases.

The entity I'm wanting to have hydrated is a 'rule', and the component that needs the rule (where the button is) is its parent. I thought that keyframe render could help so the fulcro-app has options that include :reconciler-options {:render-mode :keyframe}. I can do a very small Fulcro application that tests this out.

The 'rule' is the thing that is a tree.

See docs…that is not how to switch render in F3

https://cljdoc.org/d/com.fulcrologic/fulcro/3.0.0-alpha-20/api/com.fulcrologic.fulcro.application#fulcro-app

OMG…that markdown did not format well 😕

https://github.com/fulcrologic/fulcro3/blob/develop/src/main/com/fulcrologic/fulcro/application.cljc#L217

The functions that are pre-written to do this are in nses under the rendering package

e.g. keyframe-render/render!

Thanks for your help Tony. I fixed the problem by using computed and putting the transact! mutation that assembles the rule higher up (closer to the root of) the UI tree, remembering how important the 'this' transact! arg is is for rendering. Beforehand the transact! call was at the same depth on a different branch. No need to move to using the keyframe-renderer.

of course explicit data-based refresh is still supported (i.e. follow-on reads) for indicating data changes elsewhere in the data tree