Fork me on GitHub

@tony.kay Yep nodejs in production 😅 A few reasons for that... Shadow-cljs dev experience for node seems really nice, I get ssr for npm libs, but mostly due to the fact that appengine standard is now available for nodejs (need standard to keep the server bills low). Java is not really the best fit: 128mb instances, need to package it as unpacked uberwar, 10k app file limit, slow startup time, java apis kinda old etc.... Nodejs seems like a reasonable fit, given the constraints and the fact that my backends mostly work with the db not much processing going on. It's also easier for me since the only java I ever wrote is some interop code in clojure 🙂 so writing interop for nodejs libraries is a bit easier.


Wrote the ssr part for a few pages on a fulcro java backend app. Experience is pretty good, but still a bit of pluming. Will give it a shot to see if I can get it working as a headless app 🙂 Fulcro source code is really nice, but still a bit going on there that I have to get my head around 😄


@pvillegas12 Have you looked at AWS amplify, that could be a really good fit together with datomic ions, it can handle the front-end part for you pretty easily


someone here using "google-maps-react" ?, because when i add that to my require, it says "No such namespace: google-maps-react etc"


are you using shadow-cljs ? 🙂


is there a reason why fulcro not using hiccup or something similar? I think having markup as data makes it easier to work with


also it is a slightly more compact


Think initially because Fulcro, used to be an om-next fork, now it's standalone and the dom has improved a lot as of 2.5


an interesting read on the topic


Ure welcome :)


@kirill.salykin Many reasons, but you can easily use sablono, as pointed out. At the end of the day, I see it as a simple preference decision. My preference is how it is written, and your preference is an easy dependency add…you can even write a wrapper macro to make it “the default”


@claudiu Most of those sound like valid reasons…particularly if you have deployment target needs. In terms of headless: You can “switch out” the root render function on the reconciler options. That, and fixing up the “remote” so that it does loopback might be all that is needed. Let me know how it goes. Something like this might work:

(let [result (async/chan 1)
      render (fn [element dom-target] (async/go (async/>! result (js/ReactDOMServer.renderToString element)))
      client (new-fulcro-client  {:reconciler-options {:root-render render})]
  (mount client Root :fake-node)
  ;; then read from result chan which should have rendered result...I think???
  (async/go (async/<! result)))


The :fake-node bit will cause Fulcro to avoid trying to look up a real dom node during mount


If you have async loads in started callback, there’ll be more logic…let me know if you can get a simple render without started callback stuff with that @claudiu


sorry if i ask something stupid, i really don't know how to translate that js into cljs in fulcro


@tony.kay Thank u Mr. Tony.


@veddha.riady That will get you syntax…from there the other bits require you understand React itself.


because the code you’re showing is imperative DOM manipulation, and that is totally different from a React model, and thus very different from Fulcro


So, there is a lot to learn to explain the real differences 🙂 Read the basic docs on React, then watch some of the Fulcro tutorial videos.


Here is an implementation of the Collapse control from Bootstrap (which has animations implemented in code):


That is probably more what you’re looking for @veddha.riady


@tony.kay Thank u so much Mr. Tony, this is very helpful:grin: