Clojurians Log v2

Is there a way to filter down tests somehow / only run for a particular file? This issue suggests no: https://github.com/thheller/shadow-cljs/issues/322 Currently simply running them all using a test target:

:test
           {:target    :node-test
            :output-to "out/node-tests.js"
            :ns-regexp "-test$"
            :autorun   true}

@ritt93 for :autorun true no. otherwise yes. see node out/node-tests.js --help

ClojureScript compilation fails for me with shadow-cljs 2.12.2 and ClojureScript 1.10.844. I get a bunch of errors like this:

Multiple files failed to compile.
aborted par-compile, [:shadow.build.classpath/resource "re_frame/interop.cljs"] still waiting for #{reagent.core}
{:aborted [:shadow.build.classpath/resource "re_frame/interop.cljs"], :pending #{reagent.core}}

@flowthing is this in a :browser build?

I did change something regarding this in 2.12.2 but I haven't been able to reproduce

Hi! I’m latest shadow and tools.deps, trying to pass a config map through CLI. my alias looks like this

{:some-alias  
{:extra-deps  {
 thheller/shadow-cljs  {:mvn/version "2.11.23"}}
:main-opts   ["-m" "shadow.cljs.devtools.cli"
                                         "--config-merge" {:some "thing"}]}}

Error while parsing option "--config-merge {:some": java.lang.RuntimeException: EOF while reading

@thheller :node-test, actually.

oh. then I know.

Hi, I'm being bitten by a strange issue when trying to compile Reagent code to React components using Shadow-CLJS. I don't know whether this has to do with Reagent, build configuration or something else. The problem is that when I'm compiling Reagent to React components, the components fail to render on the React side if they use Material UI components, with the error: Uncaught Error: Minified React error #321; visit <https://reactjs.org/docs/error-decoder.html?invariant=321> for the full message or use the non-minified dev environment for full errors and additional helpful warnings. Could this be caused by the fact that Material UI components use React Hooks, which are disallowed in React class components? While debugging this, I set up a minimal test project to investigate the issue: https://github.com/tvirolai/mui-cljs-test. Here, Component1 renders while Component2 (with a Material UI icon) fails with the error. Any idea how to get around the issue? I asked around in the #clojurescript channel a couple of weeks ago, but couldn't find a workaround...

Seems to be caused by the provided config containing spaces. If I just pass an empty map {}, it seems to work.

As doing this

["-m" "shadow.cljs.devtools.cli"
                                      "server"
                                      "--config-merge" []]

--config-merge expects an EDN map argument
{:v []}

this is a deps.edn issue. it doesn't properly escape strings and as such the argument doesn't arrive correctly in the shadow-cljs code

ah, thanks, was beginning to suspect that

is it possible to point to an edn file for config-merge?

not currently but you can open an issue and I'll add it

great

@tvirolai yes, this is related to hooks. ask in #reagent, this is not a shadow-cljs issue

@flowthing should be fixed in 2.12.3

anyone want to leave a reply here: https://ask.clojure.org/index.php/10403/pros-and-cons-figwheel-vs-shadowcljs

I'm too biased to answer 😉

@thheller Many thanks, will give it a try next week!

@thheller I don’t use shadow-cljs currently but I would love you to answer 🙂 Always appreciate your input.

misread sorry. I feel like I shouldn't answer because I have never used figwheel so I'm not qualified to compare it

just listing the shadow-cljs features doesn't really answer that question 🙂

Fair enough 🙂 I’ve been juggling whether I should try shadow-cljs; not having to deal with JS bundlers (webpack etc) is very compelling; However, for my current project in React Native specifically (and I mentioned that in the thread), you still need to use Metro, even if you use shadow-cljs (I am pretty sure that’s the case); so for that setup specifically, it doesn’t feel like it makes a ton of sense for me right now;

I always say to never change a running setup, so what you have now is working properly for you and does what you expect it to do keep it

you'll still use metro regardless yes

I also don't do react-native development so I can't even speak to what figwheel might be doing differntly

I know that the loading mechanism is different but at runtime things are probably quite equal

One problem I did run into, but I’m not sure if shadow-cljs can help with this (and I don’t presume you know, because you don’t do much RN), is integrating a library like reanimated-v2

They do something unusual, in which they use React hooks that add ‘worklet’ in this style: https://docs.swmansion.com/react-native-reanimated/docs/worklets

as someone who briefly used figwheel/main and is now using shadow-cljs, I can say that setting up SCLJS takes much much much less time than figwheel/main

I was struggling to get figwheel-main up for an entire day and all it took was 15 mins with SCLJS

After that, at compile time (I believe), they look for those worklets and do some fancy stuff with them to make the animation run better.

hmm yeah no clue sorry

They achieve that via some babel plugins; the problem is, that if you have those worklets writte in CLJS

also one more thing I like about SCLJS is the doc itself. Figwheel/main doc was kind of a mess when I was using it, and it contributed to why it was taking so long to set things up.

… the babel plugin can’t understand them;

Since they are not written in JSX (I believe)

well you can always just write them in JS if needed I guess

Yes, that’s what I did 🙂

Just have a local npm package…

Which I include… and pass data from CLJS; works well enough.

But for the sake of purity, I would like it to work from CLJS! 😄:lightsaber:

But otherwise, it works.

yeah that won't work (with shadow-cljs either)

@rextruong yea the shadow-cljs docs are really top notch

That’s what I thought… thanks!

I'd be interested in seeing an open discussion between the leading lights of the cljs community 😉 on the various approaches to builds, future for cljs etc. there seem to be no end of podcasts these days but apparently never in a debate kind of format

I try to always document the "why?" when I choose to follow a different path or slightly different setup in shadow-cljs

there are a couple posts in my blog https://code.thheller.com/ and some on clojureverse or just directly in the user guide

I see that.... I really appreciate your efforts and am often sharing links to stuff you've written 👍

Seems like :target :npm-module is broken in at least 2.12.3:

IllegalArgumentException: No matching field found: stripTypePrefixes for class com.google.javascript.jscomp.CompilerOptions

Seems like it's this commit: https://github.com/google/closure-compiler/commit/79ced4fdc09a82d77f61683e33f1e48630d8279d

stripping was removed yes. what is the full stacktrace?

I mean unless you are setting this in your build config it shouldn't be used anyways?

ah right ... npm-module calls it

please open an issue or it'll get lost, can't fix it now

Done, https://github.com/thheller/shadow-cljs/issues/868

Hi! I tried to implement Inertia.js client side with Shadow-CLJS and Reagent. The documentation give this snippet who contains this following dynamic require

import { App } from '@inertiajs/inertia-react'
import React from 'react'
import { render } from 'react-dom'

const el = document.getElementById('app')

render(
  <App
    initialPage={JSON.parse(el.dataset.page)}
    resolveComponent={name => require(`./Pages/${name}`).default}
  />,
  el
) 

Source: https://inertiajs.com/client-side-setup#initialize-app

For now, I'm stuck with the expected error Uncaught ReferenceError: require is not defined

(ns myreagent.core
  (:require
   ["@inertiajs/inertia-react" :refer [App]]
   [reagent.dom :as d]))


(def el (.getElementById js/document "app"))

(defn home-page []
  [:> App {:initial-page (.parse js/JSON (.. el -dataset -page))
           :resolve-component (fn [name] (.-default (js/require (str "./Pages/" name))))}])

(defn mount-root []
  (d/render [home-page] el))

(defn ^:export init! []
  (mount-root))

@admin055 dynamic require like that is not supported, but you can probably replace it with either just a normal reference or something using shadow.loader

OK, thx for the confirmation.

I don't about shadow.loader, I'll check, thank you. When you say normal reference, you mean like that?

(defn Home [{:keys [name]}]
  [:h1 (str "Hello " name "!")])

(defn home-page []
  [:> App {:initial-page (.parse js/JSON (.. el -dataset -page))
           :resolve-component (fn [name] (r/reactify-component Home))}])

yes

I don't know what intertia.js is so I don't know what it expects, but that would be what I'd guess

OK, in my case this is not suitable because it takes away the principle of Inertia.js.

if this is about code splitting then follow https://code.thheller.com/blog/shadow-cljs/2019/03/03/code-splitting-clojurescript.html

I’m getting these strange errors in a fresh project recently:

107 |   (let [an (rum/react *active-notes)]
 108 |     [:div
 109 |      [:div [:code (pr-str an)]]
---------------------------------^----------------------------------------------
Use of undeclared Var starter.browser/an
--------------------------------------------------------------------------------

shadow version 2.11.23

@thheller Inertia.js seems interesting project that I'll tried to write an back and adapter for Clojure. From the website: "Inertia.js lets you quickly build modern single-page React, Vue and Svelte apps using classic server-side routing and controllers." The dynamic require is use to load the front component base on backend routing. Inertia read the component from the data-page attribute object.

but why does it have to be a dynamic require?

I mean you can use code-splitting but you can also case (case name "foo" ComponentA "bar" ComponentB ...)

@martinklepsch since this is with rum I'm guessing that would be related to https://github.com/tonsky/rum/issues/233

@thheller Yes the case works great but this implies adding the components by hand as the project progresses in this condition + require namespaces, etc.

well yes but at some point you could write a :target :intertia that automates all of that and emits the code optimal for intertia

you shouldn't except a generic :browser (or whatever you are using) build to match what intertia wants

I'm too drained to look into what intertia is so I really don't have a clue what it does or wants

Yeah I understand, your help has already been precious. 😉

Thx Thomas.