This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-18
Channels
- # announcements (2)
- # aws (3)
- # beginners (35)
- # boot (10)
- # cider (33)
- # cljs-dev (22)
- # clojure (58)
- # clojure-belgium (1)
- # clojure-europe (8)
- # clojure-houston (1)
- # clojure-italy (47)
- # clojure-nl (2)
- # clojure-spec (4)
- # clojure-uk (39)
- # clojurescript (12)
- # cursive (18)
- # data-science (1)
- # datomic (2)
- # emacs (24)
- # figwheel-main (29)
- # fulcro (24)
- # hoplon (14)
- # juxt (6)
- # kaocha (3)
- # nrepl (6)
- # off-topic (64)
- # om (1)
- # om-next (1)
- # pathom (21)
- # pedestal (18)
- # planck (40)
- # protorepl (1)
- # re-frame (15)
- # reagent (7)
- # reitit (16)
- # shadow-cljs (184)
- # spacemacs (4)
- # test-check (33)
https://clojureverse.org/t/whats-your-most-frequently-used-features-in-shadow-cljs/3791/2
The specs in shadow.cljs.devtools.cljs-specs
don't seem to allow destructuring like this: (defn foo [{:keys [baz/quux] :or {baz/quux :quuz}}])
.
In particular, it seems to be the combination of :or
and destructuring a namespaced keyword that's the problem. The specs allow (defn foo [{:keys [quux] :or {quux :quuz}}])
, for instance.
I'm on shadow-cljs v2.8.0.
(defn foo [{:keys [baz/quux] :or {baz/quux :quuz}}]
this is not valid. (defn foo [{:keys [baz/quux] :or {quux :quuz}}]
should be.
$ clj -Srepro -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "RELEASE"}}}' -m cljs.main
ClojureScript 1.10.520
cljs.user=> (defn foo [{:keys [baz/quux] :or {baz/quux :quuz}}] quux)
#'cljs.user/foo
cljs.user=> (foo {})
nil
cljs.user=> (defn foo* [{:keys [baz/quux] :or {quux :quuz}}] quux)
#'cljs.user/foo*
cljs.user=> (foo* {})
:quuz
I guess it seems kinda logical that :or {baz/quux ,,,}
would work, but on the other hand, I guess you could argue that quux
is the name of the variable the value is bound to and therefore makes more sense.
Anyway, TIL! Not the first time I've gotten destructuring wrong without any indication that it's not actually working...
yeah the core specs aren't enabled in CLJS by default yet so it lets some things slide
Hi, Has someone already used AirBnB DateRangePicker with reagent ? Can't make it work ... thanks
@thheller I'm testing 2.8.0 on one of my projects and get an error from the babel worker trying to process a file from @material/textfield
@r0man should be fixed in 2.8.1
. still unsure why this wasn't a problem previously but I can't reproduce the problem anymore
do I need to change anything for the new module manager. I'm using the cljs.loader namespace at the moment
(cljs.loader is now aliased to use shadow.loader, but cljs.loader would have the same issue above)
I have some files that use the module manager in the frontend. I guarded the calls to loader/set-loaded with this:
the underlying goog module loader stuff changed a bunch in the new release so I'm not surprised there are issues
please paste the contents of /home/roman/workspace/burningswell/web/.shadow-cljs/builds/server/dev/out/cljs-runtime/goog.loader.activemodulemanager.js
https://github.com/google/closure-library/blob/master/closure/goog/loader/activemodulemanager.js#L71 has the comments above
the node builds replace goog.require
with one that isn't aware of goog.loadModule
stuff
var SHADOW_REQUIRE = function(name) {
if (goog.isInModuleLoader_()) {
return goog.module.getInternal_(name);
}
return true;
};
ok thx. I'll see if the goog.require
override is required at all anymore. maybe I can just remove that hack entirely.
@r0man btw in shadow-cljs you don't need to call set-loaded!
. the tool takes care of that for you
one more question regarding modules. at the moment I have 1 module for each of my routes, like /signin, /signup etc. those module depend at the moment on 1 shared modue which contains most of the cljs code and all stuff that is shared among more than 1 module. the shared module is quite big at the moment and also contains stuff like vega & d3 which is not needed on the /signin and /signup pages. it's still moved into the shared module because 2 other modules depend on it. does shadow or the closure module loader support multiple shared modules?
I’m seeing Error building classpath. Specified aliases are undeclared: [:shadow-cljs-inject["r""e""b""l""-""1""1"]]
when using -A:rebl-11 or -A rebl-11 in recent shadow 2.8.1
@r0man say you have 2 pages that you know have common deps which should not be in :shared
:modules {:foo {:entries [] :depends-on #{:shared} :uses-foo {:entries [your.page.foo] :depends-on #{:shared :foo} ....}
:modules
{:shared
{:entries []}
:foo-shared
{:entries []
:depends-on #{:shared}}
:page-a
{:entries [your.app.page-a]
:depends-on #{:shared}}
:page-b
{:entries [your.app.page-b]
:depends-on #{:shared :foo-shared}}
:page-c
{:entries [your.app.page-c]
:depends-on #{:shared :foo-shared}}
}
the :entries []
is a shortcut when you don't have any specific namespaces that should be moved there
@thheller yes, that was my understanding. I just run into problems. I'm trying again. I think I also need to add :default true
to my main module, right?
you can pin dependencies to certain modules and shadow-cljs will warn you if they are moved out due to some requires
ie. in :foo-shared {:entries [cljs.core] ...}
will warn you since :page-a
needs cljs.core
@thheller I run into another issue with my nodejs release build. I'm using "simple" optimizations. the code that breaks is the following:
ReferenceError: Document is not defined
at /home/roman/workspace/burningswell/web/out/burningswell/server.js:2663:800
(set! js/Document ...)
is kinda questionable and should probably be (set! js/goog.global.Document ...)
but I don't see a reason why it shouldn't work now if it did work before
@thheller I'm afraid I found another issue with the module manager in advanced compilation
and it breaks over here: https://github.com/thheller/shadow-cljs/blob/01a0b4810047c719ae528f5ff2bdd26b0dcfe4fd/src/main/shadow/loader.js#L80
to me it looks like the module infos are not available. if I type shadow$loader
into the browser console it prints {}
so the modules are not registered here: https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/loader.js#L20
I looked at my main module and I do find the populated shadow$loader
object at the very beginning.
however, somewhere later in the same file this gets reset by the following code: var shadow$loader = {}
so I guess the first var shadow$loader = {"uris": { ... }};
is emitted by shadow-cljs to make the module info available. but the 2nd var shadow$loader = {}
comes from the goog.provide("shadow.loader");
call in loader.js, which unfortunatly resets this information again
@r0man shadow.loader isn't really supposed to work on a node env. how do you see a populated shadow$loader
object in the beginning?
I can probably shim some functions so that is just treats all modules as loaded given there is only ever going to be one for node
@thheller I am trying to use cljs.analyzer
namespace specially a ànalyze-file` defn in it, but while building it seems to be giving a error!
Any ideas i should try?
I am trying to analyze a cljs file on demand.the error is Use of undeclared Var cljs.analyzer/analyze-file
`
So I have a pretty minimal cljs file with reagent, but somehow the reload hook is ignored. I can't spot the error, am I missing something?
(ns reagent-movable.core
(:require [reagent.core :as r]
["react-movable" :refer [List]]))
(defn reload! []
(.. js/window -location reload))
(defonce state (r/atom (vec (map #(str "Item " %) (range 1 11)))))
(defn movable []
(let [items @state]
[:ul
(for [[idx item] (map-indexed vector items)]
^{:key idx} [:li item])]))
(defn app []
[:div
[:h1 "Movable list below"]
[movable]])
(defn ^:export ^:dev/after-load start []
(println "Mounting component...")
(r/render [app] (.getElementById js/document "app")))
try
(defn start
{:export true
:dev/after-load true}
[]
(println "Mounting component...")
(r/render [app] (.getElementById js/document "app")))
> It is possible to add multiple pieces of metadata by chaining the metadata reader macros together. For example: ^:dynamic ^ints obj would apply both the :dynamic flag and ints type-hint to obj. Metadata chains from right to left (left takes precedence).
@thheller aah i guess copying that function and manually analyzing should do the trick! Thanks!
(defn
^{:export true
:dev/after-load true}
start
[]
(println "Mounting component...")
(r/render [app] (.getElementById js/document "app")))
@arne-clojurians that repo doesn't contain the code you posted?
with the ^:export ^:dev/after-load
syntax btw. 🙂 if anyone wants to save a few keystrokes in the future
the meta data wasn't getting picked up at all. also when I removed the export. so maybe it was some kind of cache invalidation bug? it'll be hard to reproduce though