Fork me on GitHub

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?


if they did that give clojurescript a huge advantage over any other pipeline πŸ™‚


I can't remember. it might work?


ok i'll try to give it a shot


is the github issue still the best source for explaining how to build a chrome extension?


yeah. I haven't worked on it in a while


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.


what do you mean? that ns just doesn't exist?


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


that ns doesn't exist in the closure-library version shadow-cljs uses


you cannot require the closure-library from npm


Hm, I see...


So it is probably an ns that got discontinued


Hi, the certificate at is expired


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


@stijn thanks. someone reported that yesterday already. @jiyinyiyong constrols the server, I can't do anything about the cert.


@zilti which library is it?


@thheller ok, no worries, the (pretty awesome) docs are on github anyway :)


This specifically is enfocus, which relies on domina, which is the library that requires goog.dom.query


you can maybe find the last source of the goog.dom.query ns


and just put it into your classpath


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.


But thanks for helping out


unfortunately using the latest closure-compiler requires using a compatible closure-library version


and we want the latest closure-compiler version because of better JS support




so domina was probably using a deprecated API from the beginning πŸ˜›


It's sad, there really is no maintained DOM manipulation library for cljs left


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


well .. there is the closure library πŸ˜›


Yea, but when half your code consists of interop calls... Meh...


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.


Interesting, I'll take a look


FWIW I'm working on an alternative myself. nowhere near ready though.


mr. clean doesn't look that actively developed with only a snapshot release and no update in over a year?


Yea I just noticed that. Also basically undocumented


Not sure if anyone else is seeing this, but I’m getting a cert error on in firefox:


@rickmoynihan the ssl cert expired

πŸ‘ 8
Eric Ihli17:01:03

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.

(defn text-input
  [:> Text "Some title"])

(defn test-view
  [:> View
But when I move text-input out 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-load function is being called.
(defn test-view
  [:> View
   [:> Text "Title"]
I've stopped and restarted shadow-cljs server, shadow-cljs watch :app , and npx react-native start --reset-cache. Any ideas on what this might be or how to troubleshoot it?


might be react deciding to skip the update since nothing changed


what’s the ^dev/after-load function doing?

Eric Ihli18:01:24

(defn ^:dev/after-load start []
  (reload views/app-container))

Eric Ihli18:01:11

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.

Eric Ihli20:01:46

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.

Eric Ihli20:01:05

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


but your example has nothing to invalidate it


one way you could perhaps fix it (though hacky) is to mark the namespace with app-container in it as dev/always


(ns ^:dev/always my-app.views

(defn app-container ...)


this will tell shadow-cljs to reload that namespace on every change


which will create a new app-container function, helping React mark it as dirty


I think that there are two different dev reloading modes for React Native. is that still correct?


don't use :dev/always, figure out the correct way to fix it instead. always makes everything slower.


@thheller just by chance, have you done any progress on exposing api for using alternative javascript engine for execution of generated js code? I’m still waiting for some support to integrate dirac


sorry still no clue what you exactly need


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


ok, I will try to prepare some ticket on github


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

πŸ‘ 12

I wrote a bit about that but the proper docs still need to be written


nice, will study it, I actually made some progress on shadow-cljs integration in dirac[1], 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 :locals) [1]