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 https://shadow-cljs.org/ 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

Understandable

to be fair it was deprecated in 2013 https://github.com/google/closure-library/commit/e451b9dbd265adb440f8cadea431736c10b00f76

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. https://www.reddit.com/r/Clojure/comments/abc4pi/mr_clean_is_a_reagent_compatible_clojurescript/

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 https://shadow-cljs.org/ in firefox:

@rickmoynihan the ssl cert expired

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
  [title]
  [:> View
   [text-input]])

(defn test-view
  [title]
  [:> View
   [:> Text "Title"]
   [other-ns/text-input]])

might be react deciding to skip the update since nothing changed

see https://code.thheller.com/blog/shadow-cljs/2019/08/25/hot-reload-in-clojurescript.html

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

(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

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

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[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] https://github.com/binaryage/dirac/commit/a08d565a2f85072f8157ceafa6f4abd670058476#diff-7acb24e7dee86ee2bb972e97d74a6c92R24