Fork me on GitHub
#shadow-cljs
<
2020-01-14
>
Rohan08:01:00

hi all! i'm new to clojure(script) and looking at using it for some chrome extension development

Rohan08:01:37

i saw the issue explaining how to set up the build but I was wondering if content scripts support live reloading?

Rohan08:01:03

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

thheller09:01:50

I can't remember. it might work?

Rohan10:01:21

ok i'll try to give it a shot

Rohan10:01:39

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

thheller10:01:57

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

zilti10:01:55

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.

thheller10:01:33

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

zilti10:01:40

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

thheller10:01:07

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

thheller10:01:12

you cannot require the closure-library from npm

zilti10:01:39

Hm, I see...

zilti10:01:07

So it is probably an ns that got discontinued

stijn10:01:32

Hi, the certificate at https://shadow-cljs.org/ is expired

thheller10:01:48

might be. I don't know that ns but the closure folks like to remove stuff occasionally

zilti10:01:20

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

thheller10:01:47

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

thheller10:01:06

@zilti which library is it?

stijn10:01:22

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

zilti10:01:36

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

thheller10:01:01

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

thheller10:01:05

and just put it into your classpath

zilti10:01:46

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.

zilti10:01:12

But thanks for helping out

thheller10:01:58

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

thheller10:01:12

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

zilti10:01:43

Understandable

thheller10:01:06

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

zilti10:01:21

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

zilti10:01:55

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

thheller10:01:57

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

zilti10:01:14

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

thheller10:01:43

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 πŸ˜›

zilti10:01:05

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

thheller10:01:59

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

grounded_sage10:01:18

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/

zilti10:01:58

Interesting, I'll take a look

thheller10:01:06

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

thheller10:01:36

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

zilti10:01:59

Yea I just noticed that. Also basically undocumented

rickmoynihan14:01:35

Not sure if anyone else is seeing this, but I’m getting a cert error on https://shadow-cljs.org/ in firefox:

thheller14:01:05

@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
  [title]
  [:> View
   [text-input]])
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
  [title]
  [:> View
   [:> Text "Title"]
   [other-ns/text-input]])
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?

thheller17:01:59

might be react deciding to skip the update since nothing changed

lilactown18:01:47

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

Eric Ihli18:01:24

(defn ^:dev/after-load start []
  (rf/clear-subscription-cache!)
  (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.

thheller20:01:33

@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.

thheller20:01:43

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

thheller20:01:55

but your example has nothing to invalidate it

lilactown21:01:03

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

lilactown21:01:31

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

(defn app-container ...)

lilactown21:01:43

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

lilactown21:01:03

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

lilactown21:01:08

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

thheller22:01:58

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

darwin22:01:30

@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

thheller22:01:30

sorry still no clue what you exactly need

thheller22:01:12

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

thheller22:01:35

also please lets not do any of this in slack. I can't remember what we talked about last time

darwin22:01:46

ok, I will try to prepare some ticket on github

thheller22:01:13

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
thheller22:01:52

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

darwin22:01:25

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