Yes, that's exactly what you'd use in shadow-cljs. There's a whole section on using NPM packages in the documentation: https://shadow-cljs.github.io/docs/UsersGuide.html#_using_npm_packages

Yeah, it throws the same error of Uncaught TypeError: Cannot read properties of undefined (reading 'highlightAll') when I use :default instead 😞

Just read that section, it has an answer. :default is not always the solution - depends on the package.

There's a table with JS->CLJS imports translation. But it can be used in only about ~80% of the cases (just eyeballed the number based on my own experience). The rest is described by the text within that section.

FWIW consider :default deprecated. It was a non-standard addition and $default is the now standard way which shadow-cljs also support, so thats what you should be using if anything. I'll update the docs accordingly soon hopefully.

@U2FRKM4TW I used ["prismjs" :as prism] since the "prismjs" package seems to be able to be require()d normally as well, but (.highlightAll prism) now seems to not do anything at all

This is a gist for reference: https://gist.github.com/hanyuone/c919df5ac53260ae9ea4275499a42b36

Use (js/console.log prism) and see what it gives you.

I doubt this has anything to do with how you require it

and very much how you use it. you are using a react based rendering but prismjs doesn't work that way

@U05224H0W is there a way of copying this functionality from the tutorial I was following into cljs?

useEffect(() => {
  Prism.highlightAll();
}, [props.language, content]);

yes, exactly like that. I mean translate it from JS 1:1 and then lookup how to use hooks in reagent

So I'd have to use react/useState and react/useEffect in my Reagent component too instead of messing around with the r/atom?

no clue, I'm not current on how reagent works with hooks

@U013HB9EFT8 You don’t need to use React hooks to get this to work. (1) from your console log of prism, it shows that highlightAll is a field on the prism object (which you got from the require alias ["prismjs" :as prism], with a function value that takes no arguments. So, you call it simply like this in CLJS: (prism/highlightAll). (2) Since Shadow-CLJS does not load CSS dynamically into your src (at least, not by default), you will need to copy the Prism CSS file from node_modules into your resources/public CSS file. (3) I have found for the highlightAll , you will need to push it onto the event callback queue so that it runs after the DOM is updated, which you can do using a setTimeout (also described in https://betterstack.dev/blog/code-highlighting-in-react-using-prismjs/)

I’ve made a minimal example of Prism using Shadow-CLJS and Reagent:

do not use setTimeout!

@U05224H0W Ah, what should I use instead?

the correct solution is either hooks or the usual old component lifecycle hooks such as :component-did-mount or :component-did-update

I’ve tried using ;component-did-mount without the setTimeout, and it didn’t work…

never ever use setTimeout to trigger a side-effect of rendering since there is absolutely no guarantee it'll run when you intended it to

you can also just use a ref. I'd assume that prism has a highlight(domNode) in addition to highlightAll

OK, I will try to rewrite using refs…

Yes, I believe it has @U05224H0W

Thanks for the warning about setTimeout :thumbsup:

requestAnimationFrame is probably better than setTimeout, right?

no, even worse

Not for this particular case, but in some others.

Oh, how so?

react gives you ways to "hook" into the lifecycle at the point when you need it to. use them. do not ignore the lifecycle and just fire off async events in the hopes that they trigger after the lifecycle is actually done

especially with react concurrent mode and things like suspense there is no guarantee that a setTimeout (or any other) doesn't run before something is actually rendered

there is always a "you are guaranteed this node is now mounted in the document" point and callback. that is the time you want to do stuff.

everything else is just a hack, which might work but has no guarantee to do so and may break randomly for users with slower devices or slower internet connections that you use when testing

> before something is actually rendered Sounds like using such functions should still be fine when the delayed functionality does not rely on having anything rendered, right? E.g. changing the state of a component, like in this contrived example:

(defn view []
  (let [x (reagent/atom 0)]
    (fn []
      (js/setTimeout #(reset! x 1) 0)
      [:span @x])))

that'll trigger itself in an endless loop

No it's not. :)

The second reset won't render anything because 1->1.

yes it does

but it'll still trigger reagent update logic, which needs to compare

didn't say it'll render every time. I said trigger endlessly

ah hmm no I guess you are right. the watch doesn't call render again probably

That is still wrong. Reagent won't run the inner function the third time. It runs only when the properties are changed.

Right.

yeah forgot the inner fn

still a really bad way to do this given that you render one thing and then immediately another

well don't have time to get into a debate about react/reagent rendering models 😛

No arguments about it. Although I do have such a line in my own code. Don't remember the details, but none of other methods worked at all for some reason. Probably not so much because of React but rather some Reagent peculiarities since it all had to do with ratoms.

And of course removing that line right after this discussion simply magically worked. :D