That is stock React. Read the react docs.

@U0CKQ19AQ I've been reading them but I guess I'm misunderstanding the intersection with RAD reports? I guess you're referring to the part about :componentDidMount only getting called on initial render? I fail to see how it can lead to the data in the UI not being updated and why omitting that library call makes it all work.

I’m saying that componentDidMount and componentDidUpdate are REACT things. What you are seeing them do is controlled by React.

You should NOT be using them with reports. You should augment/edit the state machine of the RAD report/form if you want to augment the logic.

https://book.fulcrologic.com/RAD.html#_augmenting_form_behavior and the procedure for messing with reports is nearly identical, though the machine is different. Use the source of the machines

Hmm, they shouldn't be used with reports? I didn't know that. But I did try using ro/load-report to just call the side-effecting function before returning the unmodified uism-env and it didn't seem to do the trick.

This level of customization is really at the UISM level, and has nothing to do with RAD per se. Other than you’re modifying a state machine that your report is using.

However, I've been trying to use :componentDidMount on the defsc ro/BodyItem, not on the defsc-report. It shouldn't be used there either?

React lifecycle hooks should generally be avoided everywhere because it complects React’s rendering with your own side-effects, and coupling the two is a bad idea. This is why RAD uses UISM to control the logic

I see..

Well, for convenience I can see the desire to do so

and on BodyItem elements you’re at least not competing with the top-level logic

but I think you’re getting confused by what React gives you in those, and may be running into react keys issues as well (perhaps it isn’t remounting the rows because it thinks they are the same component with just changed data)

I mean it's just a single function call that's supposed to decorate a dom element with some syntax highlighting. I did read your advice to Gene in this thread https://clojurians.slack.com/archives/C68M60S4F/p1660066678343479?thread_ts=1660065105.976959&cid=C68M60S4F and since my customization (single fn call) is so simple, I thought it was the right choice.

I did try it like this:

ro/report-loaded (fn [uism-env]             
                   (.highlightAll js/Prism) 
                   uism-env)                

I don’t see why the report-loaded would not work, other than if there was pagination

but it seems to me the right thing to do would be to create a react component that renders text with highlighting, and use that to render the value, instead of trying to be side-effect-y on a DOM React controls

Well, I mean I don't want to re-invent the wheel to accomplish syntax highlighting when there are mature libraries that do it. Perhaps you mean something else? Is there another means of applying such a post-rendering library or..?

I’m saying you should be carefully reviewing React docs for how to do that correctly, and you should isolate that need into a React component that is properly written:

(defsc HighlightedText [this {:keys [text]}]
 {}
 ...proper code that is react compatible...)

of course you should a library to do the actual highlighting if you have one.

but a low-level js lib that is not React aware will cause you nightmares

see https://github.com/FormidableLabs/prism-react-renderer

that’s what you should be integrating with

Okay, I understand the direction you're suggesting. I thought I was making such a defsc component through this BodyItem but what you're saying about avoiding the lifecycle methods makes sense.

No, BodyItem is generating a React thing. Using a non-react library to modify the DOM it generated will never work right

it might “sorta work”, but it will never work right

hah that's exactly how it feels in the places it does work

no surprise at all

you have two libraries trying to control the DOM, that are unaware of each other

how is that supposed to work right?

I thought one was done its work and the second would do the work it needs.

but you have no control over either’s priority or when they might refresh

Bad assumption.

so it’s just a mess

Okay, thanks very much. Sorry if I missed this guidance in the docs 🙏 Back to the editor.

no worries. If you want to use low-level js libs with react, you have to be a ninja with low-level react and figure out all the gears

much easier to look for someone that’s already done that work

So always, always, always look for react components that are made using low-level libs, rather than trying to apply the libs directly.

Basically, avoid side-effecty js calls in Fulcro.

Fulcro has nothing to do with your problem/task. You’re doing low-level DOM stuff. React is always in control of that. Fulcro is a data management library that allows you to render that state with React. the rendering is ALL react.

Just because you are typing cljs code while using Fulcro does not mean Fulcro has much to do with it 🙂

I actually never really learned React directly, most of my exposure is through Fulcro. I should probably commit a few weeks study time to level up.

Yeah, it’s nice to be able to ignore it when possible, and for simple UI stuff you can. But when you get to these kinds of low-level DOM things, it’s going to be ALL react and no Fulcro (other than knowing how to get your react stuff into cljs and Fulcro’s syntax correctly)

offline/DurableEDNStore…sorry for the naming mixup

the protocol is just general storage of EDN things in arbitrary place. Mutations just happen to be encoded as EDN

No. Scroll little up to the image. The code is incomplete. There should be a Settings comp contain the S. Router. I think the complete code is elsewhere in the book.