This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-27
Channels
- # aleph (1)
- # announcements (39)
- # aws (11)
- # beginners (58)
- # calva (10)
- # cider (7)
- # clj-kondo (65)
- # cljs-dev (5)
- # clojure (90)
- # clojure-dev (48)
- # clojure-europe (23)
- # clojure-madison (1)
- # clojure-norway (1)
- # clojure-uk (40)
- # clojured (11)
- # clojurescript (20)
- # conjure (12)
- # core-async (4)
- # core-logic (4)
- # cursive (3)
- # datalevin (1)
- # emacs (7)
- # events (2)
- # fulcro (48)
- # introduce-yourself (2)
- # lsp (36)
- # malli (11)
- # missionary (1)
- # off-topic (1)
- # other-languages (72)
- # pathom (4)
- # polylith (13)
- # portal (94)
- # re-frame (14)
- # react (5)
- # releases (1)
- # sci (12)
- # shadow-cljs (29)
- # spacemacs (3)
- # vim (4)
- # xtdb (12)
I currently have a #reagent project with a landing page and an “app” page. The landing page only makes use of Reagent to create a simple modal. I want to pre-render the landing page for better SEO and pagespeed score. I currently use #reitit for client side routing. There is currently no backend. How would you recommend I go about this? I heard that #rum could be a possible way forward?
I would switch to Rum. I have used reagent for ~3 years and quite liked it for its ease of use, but I prefer Rum now even it is a little more involved. Rum also uses Hiccup and is like 99% compatible with reagent’s Hiccup, so the actual lines of code that need to change shouldn’t be too numerous. My preferred cljc stack is Rum + Pedestal
Alternatively, if you won't change that modal too often and if it doesn't share a lot of code with the main app, you can just write it in plain HTML. That's what I do, albeit for much simpler "App is loading" things.
Sure, especially given that there's https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog
And if you want to deliver your CLJS bundle right with that page (or the main module, if you use module splitting), then goog
also has a decent amount of dialog-related functionality.
Recently, I test the old way approch (to build an app) but with some modern libs. I use ornament
and rum
to style components and render them to the server (CSS in clj). I use htmx
and when I need more interactivity, I use rum
with SSR. I agree with @U4P4NREBY. rum
is very cool to use.
@U024A5W9WBG you could use a simple #nbb script to render the landing page on the server side at build time. Here's an example from @U04V15CAJ: https://github.com/babashka/nbb/blob/main/examples/reagent-ssr/example.cljs
I have a very low tech way of achieving the goal:
I just open my page in development, find the "app" <div>, copy outer HTML, and paste it into my index.html <-- it's very quick and dirty but it allows me to whack an async
on the ClojureScript load.... the HTML shows the DOM before the app loads, and you don't notice when it takes over unless I change the default page and forget to recopy it. Sorry if this is too manual, just giving an option here if there isn't a clear way to integrate it into your built tools.
How does a dialog help?
js->clj
doesn’t allow to specify a keywordise
function. Normally how do you bypass this?
If you don’t mind pulling in an extra dependency, then I think https://github.com/mfikes/cljs-bean may also do the trick for you. See here 👉 https://github.com/mfikes/cljs-bean/blob/master/doc/key-mapping.md
Why do the Clojurescript JARs include precompiled class versions of data.json and tools.reader? This is causing me some nightmares in production in Datomic Cloud. I think it is the case that the compiler will use newer source files if it finds them on the classpath, but what if the source files are older, and the class files in Clojurescript are incompatible? Or worse, the dependencies are precompiled in the target environemtn and you end up with class files for the same thing on the classpath twice (which is what I think I’m hitting). In that case you get very unpredictable results depedning on classpath ORDER. Those two things are listed as dependencies already…it seems having compiled versions in the JAR is going to lead to these kinds of problems, so why deploy jars with them?