Maybe this section could be helpful https://book.fulcrologic.com/#_the_render_method

Good stuff @UPWHQK562 ! For those in the future, there is a separate ns for fulcro dom on the server side. [com.fulcrologic.fulcro.dom-server :as dom] Use that and you're golden.

@U036UJBDM5G just be careful with performance, if you just make functions that point to functions from fulcro dom you gonna have a performance hit, that's because in Fulcro all the dom things are both macros and fns, when nothing is dynamic (eg: (dom/div {} "foo") the macro is gonna be used, making that translate into a direct call to the React dom fns at compile time, but when things are dynamic, Fulcro falls back to use fn versions that can handle those variables\

In practice the performance difference is usually negligible, but I did spend a ton of time getting that all working right in order to get low-level raw react DOM performance.

That said, if you don’t include nil or an empty props map, those optimizations are often not able to be applied 😉

(div (p "hello"))

(div nil (p "hello"))

I haven't really dug into customizing kondo, but maybe we could have a lint for that?

@UPWHQK562 unfortunately it would highlight about 80% of people’s code, and since it only makes a diff in really heavy pages with lots and lots of elements (like a huge table) I think it would just be a lot of useless noise.

I think we did some performance measurement, and the macro versions are a lot faster; however, most of the real CPU hogging is DOM diffing and modding, so it turns out to be insignificant in most cases due to Amdahls’s Law . https://en.wikipedia.org/wiki/Amdahl%27s_law

These DOM calls in our code typically take less than 10% of the total time, so even doubling their speed can at most shave off about 5% of a render frame’s overhead.

On the note of what started this thread... Moving from cljs to cljc was surprisingly easy. I guess it varies from app to app, but I was expecting more work. Doing so has really improved my dev experience. I'm really digging the xplatform approach.

Yeah, I did a lot of work to make sure all of the Fulcro nses work well in CLJC. The DOM one was the only weird one, because of this macro + function stuff. There’s no other way to do that other than to use alternate nses. I personally lean towards making everything in my apps CLJC. I find it makes dev cycle pretty nice, in that I can test code in CLJ (even when its primary target is CLJS). Occasionally the differences pop up, but surprisingly rarely.

Good to hear it was a smooth transition @U036UJBDM5G. I've been thinking about making that move eventually as well. It's somewhat surprising to me to hear that it improves the dx.

How do people generally handle the http-remote ns with DF/load!?

What do you mean? df is CLJC

you mean how do you make a remote that works in CLJ?

so typically I don’t run the fulcro app itself in CLJ, but if you want to, a remote is just a map that has a function at the :transmit! key. All you have to do is take the transaction it wants run on the “server”, run it on your parser, and then call the correct callback to “return” the result. See mock-http-server (which does this for CLJS apps that don’t want a server…same pattern)

https://github.com/fulcrologic/fulcro/blob/develop/src/main/com/fulcrologic/fulcro/networking/mock_server_remote.cljs

That looks far more straightforward than I had imagined... But it raises another question, so when you run your app in clj, where do you keep your state if not in the fulcro app client db?

I don’t understand the question. If you run a headless (or SSR) version of your client app in CLJ, it still has a “client side db”…it’s an atom in the app instance.

but for me the whole point of doing that is either SSR (rendering a single frame) or for trying something out where you’re more interested in the state change than the rendering.

There is a combination of my knowledge of Fucro still being glaringly incomplete and having an atypical use-case/solution. It's working out well, but admittedly my question may show off my ignorance. I appreciate the help. I misunderstood your answer... I think.