Fork me on GitHub

Hi folks, I'm not experienced anough Fulcro, but is it possible for me to create alternative render format (e.g. something like this: {tag: :div, :attrs {}, :children [...], [:react-id ...]}), which then can be used on jvm-based Clojure Fulcro app with state stored inside simple atom? I'm completely okay to full re-renders, just want to have component tree rendered for each state transitioned.


@s_zharinov Fulcro already can do server-side rendering, and it stores state in an atom. See


Thanks, looks like I've figured out how to "render" into data-structure, in the same manner render-to-str does. My point was to create "headless" fulcro instance and run unit tests against it, without any JS-side machinery.


cypress is nice


this is not unit testing, but for testing UI I think it is about the best thing going right now:


That's exactly what I want, but with unusual approach: what if we can completely "simulate" application entirely in JVM. Once it's possible to run app with "dummy" DOM/widgets/etc, it should open the possibility for stateful generative testing, as well as coverage reports.


I found one mention from docs: It isn't recommended approach, but still want to try.


all of the code is CLJC so you can do exactly that sort of thing. Technically you can plug in alternate rendering (see keyframe-render), and you could make your own replacement server dom lib that has the same API but returns CLJ data structures.

👍 4

Is there a piece of writing somewhere that goes into the differences between fulcro and reagent/reframe and their respective affordances and philosophies? I don’t want to start a flame war, I’m just curious.

👍 4

I gave a talk that explains what makes fulcro different, for non-fulcro people


the talk goes into more detail, but one of the biggest differences is fulcro is full stack (but any backend is pluggable)


most stacks only have normalized data stores for the server and store denormalized data on the client (or leave it up to you to normalize and query yourself)

👍 4

the talk explains better with pictures and examples


hah, i just had that queued up for viewing later. and yeah, that’s the main standout feature. thanks for responding!

👍 4

also worth considering what the creators of both frameworks were building when they made these tools


both have been on the defn podcast explaining the origins i believe


ooh, i’d love to hear those. i’ll look those up.