This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-12
Channels
- # adventofcode (2)
- # aleph (2)
- # announcements (5)
- # aws (5)
- # babashka (25)
- # beginners (167)
- # calva (8)
- # cider (1)
- # clj-kondo (3)
- # cljsrn (19)
- # clojure (87)
- # clojure-conj (7)
- # clojure-dev (19)
- # clojure-europe (1)
- # clojure-italy (14)
- # clojure-losangeles (1)
- # clojure-nl (4)
- # clojure-norway (3)
- # clojure-spec (18)
- # clojure-uk (29)
- # clojuredesign-podcast (3)
- # clojurescript (40)
- # clojurex (11)
- # core-async (13)
- # core-logic (2)
- # cursive (16)
- # data-science (4)
- # datascript (10)
- # datomic (53)
- # emacs (1)
- # events (15)
- # fulcro (71)
- # jobs (1)
- # jvm (2)
- # malli (4)
- # nrepl (2)
- # pathom (74)
- # re-frame (1)
- # reitit (19)
- # remote-jobs (1)
- # rewrite-clj (18)
- # ring (2)
- # shadow-cljs (132)
- # spacemacs (22)
- # tools-deps (65)
sounds uncannily similar to what happens to type info in ocaml (and probably other HMs), only for JS, which only makes it that much more insane
does clojurescript metadata have to be attached inline? attaching the export metadata with 'with-meta' or 'vary-meta' doesn't seem to work
@nickmbailey yes, needs to be completely static. are you trying to attach the export meta in a macro?
Whats the best way to inspect props that are passed in a react app at run time. Assuming a typical shadow-cljs setup in development mode? 1. The browsers react "components" view seems munged by the clojurescript, as in you just get "Object". i suppose thats workable because you can open it up. 2. There are contexts where it seems hard to even print the state, possible due to this issue: https://github.com/binaryage/cljs-devtools/issues/25. Though the fix at leasts lets you print the props without an error.
https://github.com/Lokeh/react-hmr-cljs/blob/master/src/react_hmr/react.cljs#L15-L19
yea. š .That lets me print the props, which might be as good as it gets and all i need in this case. I'm just curious if i should be looking elsewhere, as this issue would seem to be very common place.
what I typically do is navigate to the component in the React DevTools, then click the ābugā to log the component and itās state / props to the console
thheller, Iām curious what your thoughts are (if any) about ādynamicā code splitting
it seems to be getting quite popular in e.g. webpack / parcel / etc. to determine how to split the bundle based on usage of dynamic import()
I see the appeal, as setting up an entrypoint can be onerous if you want to just lazy load a component or whatever
I don't like import()
creeping into libraries though. that seems like a horrible idea
yes definitely. especially since it relies on bundler behavior. maybe once dynamic import is in most browsersā¦ but even then, dynamically importing a lib could cause a cascade of :poop: šµ
yeah. Iām wondering if there could be a way to macro-away some of the pain of :modules
. I assume it would rely on something shadow-cljs specificā¦
I experimented with a bunch of things a while ago but really the coming up with a good "graph" is the problem
with "automatic" webpack style config everything is kinda random and all sorts of weird sized chunks
what would be neat is a cli tool that would do all the neato graph analysis and make a recommendation
I wish there was a way to at least separate the code you write to import from the module config
https://code.thheller.com/blog/shadow-cljs/2019/03/03/code-splitting-clojurescript.html
that is the latest bit of "sugar", so you don't have any references of "modules" in your code. don't need to remember what something is in
Right yes. I remember I wrote a bunch of module loader sugar for my last employer before that existed
shadow-cljs build hooks can specify what compilation stage they are relevant in, via shadow.build/stage
. Is there additional support for other things like shadow.build/mode
to control whether or not the hook activates in dev mode or release mode?
just check it in the build hook and do nothing if it doesn't match your intended mode
Yeah that was my fallback. Was curious š
@thheller Iām getting warnings about the absence of refactor-nrepl and cider-nrepl when compiling from a clojure (i.e. starting the shadow-cljs server and compiling stuff). It doesnāt seem to stop me from compiling, but I just want to make sure with you whatās happening there. Like, should I actually require those two libs when compiling?
Alright, cool. Thanks!
Much as I love looking at efforts to do away with React, then I remember how much work is to actually produce a nice drag-and-drop component like react-beautiful-dnd
and cry in my coffee.
it is nice to tap into the react ecosystem sometimes ... but in my experience that has been more trouble than actual benefit. constantly breaking packages/apis or just overly bloated packages.
Yeah, Iām in this situation. I decided to drop to the React ecosystem only when strictly necessary, even we end up with a bunch of āNIHā stuff. The recent hooks work has finally allowed us to make use of smaller dependencies that we could easily rewrite if we ever wanted to. Instead of relying, say, on the steaming pile of react-bootstrap.
@thheller sorry to be bothering you so much. When I set :prepend
on a build hook, the compiler seems to ignore it and compile the js with the previous value of :prepend
. So if itās unset, nothing is prepended. If itās some value, itāll be that value. Is this use case explicitly unsupported by build hooks?
@thheller (assoc-in build-state [:shadow.build/config :modules :main :prepend] licenses)
Iāve tried it in both :configure
and :compile-prepare
neither seems to work
So before this, Iāve been running a tools deps alias, modifying the config before calling release
oh! iāll try that š
@thheller doesnāt work yet š
Could it be :shadow.build.closure/modules
?
:shadow.build.closure/modules
is a copy of :shadow.build.modules/modules
after optimizations. since that can adjust things
thereās also a :shadow.build.modules/config
with similar looking stuff š
oof, modifying a vector index is a little scary
trying it out
I tried (assoc-in build-state [:build-modules 0 :prepend] licenses)
and it still doesnāt work. I ran (keys build-state)
and I canāt find any :build-modules
in the list. Could it be that my version is too old? Iām on 2.8.66, and when i checked the recent commits, there was nothing that jumped out at me that signaled that i needed to update.
:configure
module config is actually done after configure. so :shadow.build.modules/config
should have worked?
oh doh .. I gave you the wrong key I think. should be :shadow.build.modules/config
not :shadow.build.modules/modules
hahaha this is hilarious.
Okay, so :build-modules
works in :compile-prepare
. Will try it out in :shadow.build.modules/config
now
it goes from the build config -> :shadow.build.modules/config. then after configure they are sorted and :build-modules
is created (no longer a map)
optimize takes :build-modules
and creates :shadow.build.closure/modules
(including some of the GCC compiler data) otherwise the same
:flush
then takes either of those keys to flush the output but :prepend
must be set before so it doesn't mess with the source maps
That does feel quite convoluted š
Hi! When I start shadow-cljs with :browser-test , insead of :app, my spec instrumentation doesn't work. The specs work with (exercise fully-qualified-ns/spec), but I can't instrument functions either through code or repl. Any ideas? I don't even know where to look
@thheller okay, can confirm, :shadow.build.modules/config
works when i do it in :configure
@thheller thanks for the help!
@publicz try version 2.8.60. instrument and check works for me on that version. but when I upgrade it does not.
Thanks, I'll try!
what is the particular problem with instrument? I never use it myself but I'm not aware of anything that would have changed its behavior since 2.8.60?
I have a :node-library
that Iād like to play with in a REPL, but Iām unsure how to load it
I used that command, but when I (require 'myapp.backend.parser)
It says it canāt find it
{:type clojure.lang.ExceptionInfo
:message "The required namespace \"myapp.backend.parser\" is not available, it was required by \"cljs/user.cljs\"."
:data {:tag :shadow.build.resolve/missing-ns,
Ughā¦the file is where it should be but I didnāt name the namespace correctly in the actual file :man-facepalming:
trying to start a new project here, using deps, but for reason I'm getting
Could not locate shadow/cljs/devtools/cli__init.class, shadow/cljs/devtools/cli.clj or shadow/cljs/devtools/cli.cljc on classpath.
shadow 2.8.69
is this a new thing? I'm looking at old projects, it wasnt needed before
the npm module no longer adds itself to the classpath if youāre using deps.edn or leiningen
thanks!
@thheller i got the export metadata addition working with a macro btw. thanks for the help
does the googe closure compilation eliminate unused code from clojurescript core too?
sweet
@thheller I got an require error on versions 2.8.61 and 2.8.64 (:target :node-script) when running cljs.spec.test.alpha/check but just tried on 2.8.69 and it works again. Sorry for the inconvenience
hi there! first of all - thanks @thheller for the shadow-cljs - this tool makes working with ClojureScript a pleasure! second, I have some wired behavior when I start shadow-cljs from VS Code (and Calva). At first everything look OK, source code compile, server is starting (and I can see my app), but then when I change my file and save it I get such error message in the terminal: `Evaluating file: fire.cljs no source by id: [:shadow.build.classpath/resource "project/fire.cljs"] {:id [:shadow.build.classpath/resource "project/fire.cljs"]} ExceptionInfo: no source by id: [:shadow.build.classpath/resource "project/fire.cljs"] shadow.build.data/get-source-by-id (data.clj:167) shadow.build.data/get-source-by-id (data.clj:164) shadow.build.compiler/remove-dead-js-deps/remove-fn--12063/fn--12064 (compiler.clj:1089) clojure.core/complement/fn--5669 (core.clj:1441) clojure.core/filter/fn--5893 (core.clj:2817) clojure.lang.LazySeq.sval (LazySeq.java:42) clojure.lang.LazySeq.seq (LazySeq.java:51) clojure.lang.ChunkedCons.chunkedNext (ChunkedCons.java:59) clojure.core/chunk-next (core.clj:708) clojure.core.protocols/fn--8154 (protocols.clj:137) clojure.core.protocols/fn--8154 (protocols.clj:124) clojure.core.protocols/fn--8114/G--8109--8123 (protocols.clj:19) clojure.core.protocols/seq-reduce (protocols.clj:31) clojure.core.protocols/fn--8146 (protocols.clj:75) clojure.core.protocols/fn--8146 (protocols.clj:75) clojure.core.protocols/fn--8088/G--8083--8101 (protocols.clj:13) clojure.core/reduce (core.clj:6828) clojure.core/into (core.clj:6895) clojure.core/into (core.clj:6887) shadow.build.compiler/remove-dead-js-deps/remove-fn--12063 (compiler.clj:1091) clojure.core/update (core.clj:6196) clojure.core/update (core.clj:6188) shadow.build.compiler/remove-dead-js-deps/fn--12068/fn--12069 (compiler.clj:1097) clojure.core/map/fn--5866 (core.clj:2753) clojure.lang.LazySeq.sval (LazySeq.java:42) clojure.lang.LazySeq.seq (LazySeq.java:51) clojure.lang.RT.seq (RT.java:535) clojure.core/seq--5402 (core.clj:137) clojure.core.protocols/seq-reduce (protocols.clj:24) clojure.core.protocols/fn--8146 (protocols.clj:75) clojure.core.protocols/fn--8146 (protocols.clj:75) clojure.core.protocols/fn--8088/G--8083--8101 (protocols.clj:13) clojure.core/reduce (core.clj:6828) clojure.core/into (core.clj:6895) clojure.core/into (core.clj:6887) shadow.build.compiler/remove-dead-js-deps/fn--12068 (compiler.clj:1098) clojure.core/update (core.clj:6196) clojure.core/update (core.clj:6188) shadow.build.compiler/remove-dead-js-deps (compiler.clj:1095) shadow.build.compiler/remove-dead-js-deps (compiler.clj:1084) shadow.build.compiler/compile-all (compiler.clj:1347) shadow.build.compiler/compile-all (compiler.clj:1194) shadow.build.api/compile-sources (api.clj:256) shadow.build.api/compile-sources (api.clj:248) shadow.build.api/compile-sources (api.clj:260) shadow.build.api/compile-sources (api.clj:248) shadow.cljs.repl/repl-load-file* (repl.clj:292) shadow.cljs.repl/repl-load-file* (repl.clj:232) shadow.cljs.devtools.server.worker.impl/do-repl-rpc (impl.clj:832) shadow.cljs.devtools.server.worker.impl/do-repl-rpc (impl.clj:792) shadow.cljs.devtools.server.worker.impl/fn--13594 (impl.clj:876) shadow.cljs.devtools.server.worker.impl/fn--13594 (impl.clj:875) clojure.lang.MultiFn.invoke (MultiFn.java:234) shadow.cljs.devtools.server.util/server-thread/fn--13177/fn--13178/fn--13186 (util.clj:285) shadow.cljs.devtools.server.util/server-thread/fn--13177/fn--13178 (util.clj:284) shadow.cljs.devtools.server.util/server-thread/fn--13177 (util.clj:257) java.lang.Thread.run (Thread.java:834)` any ideas what am I doing wrong?
what does your shadow-cljs.edn file look like?
I feel this is a classpath or organizational issue. As in, maybe the build-id of the app isn't what your telling your repl to look for.
{:source-paths ["src/dev" "src/main" "src/functions" "src/tools" "src/test"] :dependencies [[binaryage/devtools "0.9.10"] [reagent "0.8.1" :exclusions [cljsjs/react]] [re-frame "0.10.9" :exclusions [cljsjs/react]] ; [day8.re-frame/http-fx "v0.2.0"] [secretary "1.2.3"] [cljs-bean "1.5.0"] ;;https://github.com/mfikes/cljs-bean [cider/cider-nrepl "0.22.4"] [testdouble/clojurescript.csv "0.4.5"] ] ; :nrepl {:port 8777} :builds {:app {:target :browser :output-dir "public/js" :asset-path "/js" :modules {:app {:init-fn project.core/init :preloads [devtools.preload]}} :devtools {:http-root "public" :http-port 8000}} :browser-test {:target :browser-test :ns-regexp "-test$" :runner-ns shadow.test.browser :test-dir "tests/browser-test" :devtools {:http-root "target/browser-test" :http-port 8290}} :karma-test {:target :karma :ns-regexp "-test$" :output-to "tests/karma-test.js"} :functions {:target :node-library :output-to "functions/cljs-libs.js" :exports-var project.cloud-functions/declaration} :tools {:target :node-script :output-to "tools/tools.js" :main project.tools/main}}}