@pez just wanted to say thanks for https://github.com/PEZ/rn-rf-shadow , got this up & running fast. a bit easier than my previous experience using re-natal I see that the README notes source-maps aren't working, but according to https://clojureverse.org/t/upgrading-the-react-native-support/4669/21 they might be after shadow-cljs 2.8.44. Will report back with my findings tomorrow

@quest , cool! I get a bunch of warnings and errors when starting things up, but things work. Do you have those messages as well, or have you found out how to fix it?

In the shadow-cljs user guide (Section 4.1 Source Paths), it says: > It is not recommended to separate source files by extension (eg. src/clj, src/cljs, src/cljc). For some reason this is widely used in CLJS project templates but it just makes things harder to use. https://shadow-cljs.github.io/docs/UsersGuide.html#_source_paths I've always done this for two reasons, first to make it easy to specify what's included in my frontend and backend builds, but also just to have things nicely separated when I'm developing. I'd be interested to hear why shadow recommends not to do this? I'm always up for simplifying things

@conan splitting source paths makes sense sometimes. splitting by file extension does not IMHO. say you write a macro file for CLJS that is never used in CLJ. do you put it in src/clj just because? src/cljc just makes sharing annoying too. I pretty much always use setups like src/main/my/amazing/frontend/* and src/main/my/amazing/server/*

still easy to separate out files when building uberjars etc. just exclude my/amazing/frontend*

src/frontend and src/backend works too

my main gripe is separating by file extension thats all

Hmm, I see. It's sharing the code between the two that my src/cljc folder is for

src/main/my/amazing/shared works fine too

I like the idea of being explicit about what each folder is for though, with frontend and backend for example. I've never come across a situation where that wasn't a 1:1 mapping with file extension though

have you written macros?

Only very occasionally, but also only ever in clj, for use in clj

Anyway, this all feels like preference, so it's good that there's lots of flexibility. There's no technical advantage as far as shadow is concerned though?

I can definitely see how the macro situation would cause me to rename my folders though

if this setup works for you then use it

I just think it is unnecessary confusing

shadow-cljs doesn't care what the names are as long as the source-path is setup correctly

also https://code.thheller.com/blog/shadow-cljs/2018/02/08/problem-solved-source-paths.html

so historically there may have been reasons as to why separating made sense

oh good post, that answers a question i had about why :modules is needed too, thanks!

Hey guys, Was there any significant change in the websocket connection from the browser to the repl from 2.8.68 to 2.8.69? If I do the update, my application doesn't connect to the repl anymore :thinking_face:

This message does not show up on the browser console in 2.8.69 to me:

shadow-cljs: WebSocket connected!
browser.cljs:26 shadow-cljs: REPL session start successful

no?

I wish I had more useful information, but this is what appears in my browser's console in 2.8.69:

Installing CLJS DevTools 0.9.10 and enabling features :formatters :hints :async
client.cljs:356 Installing Fulcro Inspect {}

Installing CLJS DevTools 0.9.10 and enabling features :formatters :hints :async
client.cljs:356 Installing Fulcro Inspect {}
browser.cljs:26 shadow-cljs: WebSocket connected!
browser.cljs:26 shadow-cljs: REPL session start successful

assuming you are running shadow-cljs watch the-build?

In 2.8.68 I'm able to connect emacs to the repl using CIDER. In 69, I get a "no client connected to the repl" sort of message and I can't evaluate stuff

Yes!

any clue in the browser console?

there should be a websocket request open?

maybe that is timing out or something?

I will take a look on the network tab. Didn't try it before, just a sec

you can try checking if shadow.cljs.devtools.client.browser exists in the browser console?

Ok, so, on 2.8.69, there is no websocket connection attempt on the network tab in the console, and shadow.cljs.devtools.client.browser.cljs is loaded in the browser (prints in the thread)

> (prints in the thread)

what does that mean?

Printscreens in the slack thread xD

please actually run what I pasted in the browser console

if that namespace is loaded it should have connected directly on startup? no clue why it wouldn't have?

Yes, the reference exists

If I type shadow.cljs.devtools.client.browser.cljs in the console, I get an object back

I'm assuming without the last .cljs?

because that would be wrong?

oops, excuse me. Yes, without the .cljs suffix

what is shadow.cljs.devtools.client.env.enabled?

undefined

oh. do you use lein or deps.edn?

hit up shadow-cljs clj-repl then ( "goog/base.js"). I'm guessing you have an old closure-library version

should be 0.0-20191016-6ae1f72f

Yes, we do use lein here!

shadow.user=> ( "goog/base.js")
#object[java.net.URL 0xdad8889 "jar:file:/Users/lucas.barbosa/.m2/repository/org/clojure/google-closure-library/0.0-20170809-b9c14c6b/google-closure-library-0.0-20170809-b9c14c6b.jar!/goog/base.js"]

we do have a mismatch :thinking_face:

yes, that is the rather old one

[com.google.javascript/closure-compiler-unshaded "v20191027"]

   [org.clojure/google-closure-library "0.0-20191016-6ae1f72f"]
   [org.clojure/google-closure-library-third-party "0.0-20191016-6ae1f72f"]

you can add those manually I guess

@thheller what made you suspect an out of date google closure?

the .env/enabled is a goog-define and goog.define was changed in the latest closure compiler/library release

shadow-cljs displays an empty error message when I do something stupid with macros:

;; test.clj
(defmacro dummy []
  `(defmulti x ~identity))

;; test.cljs
(dummy)

------ ERROR -------------------------------------------------------------------
 File: /.../test.cljs
Error in phase :compilation

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------

I’ll try the dependency bump and let you guys know! Thanks for the awesome support @thheller !

Is there a way to not include a component in a release build? I guess other than module splitting, some sort of function/macro that depends on :shadow.build/mode

I’m trying to implement code splitting based on https://code.thheller.com/blog/shadow-cljs/2019/03/03/code-splitting-clojurescript.html , but instead of reagent I’m using hx. Everything works fine, but hot reloading doesn’t seem to work. Shadow does detect the changed code, and does reload the changed namespace, and does call the “after-load” fn, but then React seems to skip over rendering the lazy component.

I’m using the “trick” to wrap the component in an extra level, but doesn’t seem to have any effect.

@orestis what did you try? the demo.util used in that post should be working with hot-reload

but you can't skip the step done in demo.util

(defn lazy-component* [loadable]
  (React/lazy
   (fn []
     (js/console.log "still lazy?")
     ;; React lazy expects a promise, that returns an ES6 module with a React Component as default export
     (-> (shadow.lazy/load loadable)
         (.then
          (fn [root-el]
            (if-not js/goog.DEBUG
              ;; in production mode, just do that
              #js {:default root-el}
              ;; in dev mode, we need wrap the loaded component one
              ;; extra level so live-reload actually works since React
              ;; will keep a reference to the initially loaded fn and
              ;; won't update it
              #js {:default (fn [props]
                              (js/console.log "lazy render")
                              (js/console.log (@loadable #js {}))
                              (React/createElement @loadable props)
                              (hx/f [LazyComponentWrapper {:loadable loadable :props props}])
                              (hx/f [LazyWrap {:loadable loadable :props props}])
                              )})))))))

I can’t even get the “lazy render” to log out.

^There’s a bunch of experiments with different approaches, but non of them work.

yes cause they are all wrong 😛

the :default (fn [props] is called ONCE on initial load

*They work with the first render, but not on the hot reload.

it'll never be called again

so whatever will be happening again ... must deref the loadable

(r/reactify-component (fn [props] [@loadable props]))

Right, so I need to close over the loadable, and deref it again on render, right?

yes

That’s what the LazyComponentWrapper thing does, but it doesn’t seem to have any effect.

(hx/defnc LazyComponentWrapper [{:keys [loadable props]}]
  (js/console.log "LOADABLE  dereffed" @loadable)
  [@loadable (bean props)])

The log doesn’t even print.

well that might be hx short circuiting because neither loadble nor props changed?

dunno what it actually does

I think it’s React short-circuiting, because it’s a functional component.

react doesn't short circuit, unless you memo stuff

hx doesn’t either — unless I’m very confused.

I’m knackered for the day, but thanks for the confirming the general approach — return a wrapper that will deref the loadable on every render, to get the latest version.

I’ll try a minimal shareable repro and see what happens.

aaaaaaaaaaaaaarghh ... sabotaged by vscode ...

trying to write a description of the component stuff I've been working on and vscode just deleted half of it ...

seriously .. I don't even know how it got into the state it is in now ... pressing undo/redo just makes arbitrary changes and makes things worse

W T F

guess I'm done with vscode

are you using vim-mode? i heard it has wierd interactions with the normal undo/redo system

indeed I do

ah