This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (1)
- # aws (3)
- # beginners (75)
- # boot (1)
- # bristol-clojurians (2)
- # clj-kondo (18)
- # cljs-dev (5)
- # cljsrn (10)
- # clojure (64)
- # clojure-dev (15)
- # clojure-europe (3)
- # clojure-india (2)
- # clojure-italy (9)
- # clojure-madison (1)
- # clojure-nl (9)
- # clojure-norway (9)
- # clojure-spec (11)
- # clojure-uk (206)
- # clojurescript (30)
- # copenhagen-clojurians (1)
- # data-science (1)
- # datascript (2)
- # datomic (27)
- # emacs (1)
- # events (1)
- # fulcro (12)
- # gorilla (1)
- # jobs (2)
- # kaocha (2)
- # leiningen (4)
- # lumo (7)
- # malli (1)
- # off-topic (2)
- # pathom (14)
- # pedestal (5)
- # quil (3)
- # re-frame (8)
- # reitit (3)
- # remote-jobs (16)
- # ring-swagger (1)
- # shadow-cljs (70)
- # tools-deps (7)
- # vim (5)
- # vrac (1)
hi all! i'm new to clojure(script) and looking at using it for some chrome extension development
i saw the issue explaining how to set up the build but I was wondering if content scripts support live reloading?
is the github issue still the best source for explaining how to build a chrome extension?
Is there a way I can tell shadow-cljs to by default provide the goog.* namespaces? I am using a library that gives me
The required namespace "goog.dom.query" is not available.
It is a namespace from the Google Closure libraries. Since a library I use depends on it, a simple
(:require ["google-closure-library"]) doesn't fix it
might be. I don't know that ns but the closure folks like to remove stuff occasionally
I noticed in general that the state of cljs libraries is desolate. Most seem to have been discontinued and are just waiting to stop working
This specifically is enfocus, which relies on domina, which is the library that requires goog.dom.query
Eh, that is a crude hack, not a fix 😕 I'll look at the sources of the library when I have time. Maybe it is a rather straightforward fix.
unfortunately using the latest closure-compiler requires using a compatible closure-library version
to be fair it was deprecated in 2013 https://github.com/google/closure-library/commit/e451b9dbd265adb440f8cadea431736c10b00f76
Eh, Domina probably started out using it when it wasn't deprecated yet, a substantial part of the code hasn't seen any updates since 8 years
I don't mind interop ... its one of the reasons I'm even using clojure(script) in the first place. imagine not being able to do that 😛
With Clojure you get by most of the time with using Clojure libs and rarely have to touch Java interop at all, which means more idiomatic code. But wanting to write idiomatic ClojureScript when almost all you have is interop just leads to a ton of annoying glue code
yeah the CLJS community adopted React too much. everything else kinda got left behind. one might think that React is the only thing out there when looking at CLJS
Mr Clean is an interesting alternative. I'm not sure if it gets rid of your pain point @zilti. Gives a nice option where you can still lean heavily on how everyone else is building with cljs it's actively maintained as a side project. https://www.reddit.com/r/Clojure/comments/abc4pi/mr_clean_is_a_reagent_compatible_clojurescript/
mr. clean doesn't look that actively developed with only a snapshot release and no update in over a year?
Not sure if anyone else is seeing this, but I’m getting a cert error on https://shadow-cljs.org/ in firefox:
I just extracted a reagent form to a new namespace in a new file and something with hot-reload seems to have broken. This first example works fine, I can edit the text "Some title" and the app hot-reloads and I see the changes.
But when I move
(defn text-input  [:> Text "Some title"]) (defn test-view [title] [:> View [text-input]])
text-inputout into another namespace and edit the text there, I don't see the changes in the app until I manually reload, even though on save a build is triggered and the dev console reports that the
^dev/after-loadfunction is being called.
I've stopped and restarted
(defn test-view [title] [:> View [:> Text "Title"] [other-ns/text-input]])
shadow-cljs watch :app, and
npx react-native start --reset-cache. Any ideas on what this might be or how to troubleshoot it?
(defn ^:dev/after-load start  (rf/clear-subscription-cache!) (reload views/app-container))
Another bit of possibly useful info: I edit and save the file with my new-namespace and the
dev/after-load function gets called but the view doesn't refresh. Then, I add a meaningless extra newline at the end of some other file (just so emacs sees a change and allows me to save it) and save it. Then the view that I was trying to hot-reload/hot-refresh actually refreshes.
@ericihli as I mentioned the re-render likely just stops at the
test-view. it didn't change so reagent or react (don't exactly know who is reponsible) stops there.
That's the thread I'm pulling on now. I tried saving a reference to my outermost wrappers
this and then using reagents
(force-update @wrapper-this true) to nuke and re-render everything, but that resulted in the same behavior, no update.
But even that was just a trial and error theory. Maybe I'm misunderstanding which "this" I'm getting a hold of. Or maybe I'm misunderstanding what reagent's
force-update does. So still have a lot of exploring to do.
you force update the outer most component. it starts rendering and may decide at any point to stop. in re-frame you'll usually have some subs or so which are invalidated so it'll continue
one way you could perhaps fix it (though hacky) is to mark the namespace with
app-container in it as
I think that there are two different dev reloading modes for React Native. is that still correct?
:dev/always, figure out the correct way to fix it instead. always makes everything slower.
if you put together a ticket/proposal I can look at it but without a reference of what you actually need I can't do much
also please lets not do any of this in slack. I can't remember what we talked about last time
FWIW I'm still working on the "inspect" feature I started. currently getting rid of react but making good progress. once thats done I'll get back to the shadow.remote feature that inspect is built upon. that might be of interest for dirac
I wrote a bit about that but the proper docs still need to be written https://github.com/thheller/shadow-cljs/blob/master/doc/remote.md
nice, will study it, I actually made some progress on shadow-cljs integration in dirac, but forgot most details
one of the problems I remember is that I needed for you to pass some extra compilation env stuff down to cljs compiler (scope