This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-24
Channels
- # announcements (26)
- # babashka (9)
- # beginners (63)
- # calva (2)
- # chlorine-clover (22)
- # cider (2)
- # cljsrn (8)
- # clojure (36)
- # clojure-europe (36)
- # clojure-italy (5)
- # clojure-nl (76)
- # clojure-spec (9)
- # clojure-uk (8)
- # clojurescript (39)
- # conjure (24)
- # cursive (19)
- # data-science (1)
- # datascript (10)
- # datomic (1)
- # emacs (2)
- # events (5)
- # figwheel-main (9)
- # fulcro (21)
- # graalvm (1)
- # helix (5)
- # jobs (1)
- # jobs-discuss (1)
- # kaocha (1)
- # leiningen (4)
- # meander (2)
- # off-topic (22)
- # re-frame (16)
- # reitit (3)
- # rewrite-clj (75)
- # rum (1)
- # sci (51)
- # shadow-cljs (110)
- # tools-deps (16)
- # vrac (9)
- # xtdb (23)
Thanks for the fix @thheller That release builds re-frame fine. Just to confirm does this change the table in the docs at https://shadow-cljs.github.io/docs/UsersGuide.html#_using_npm_packages ?
@superstructor it changes the table for import
inside .js
files on the classpath. CLJS remains the same.
I updated https://shadow-cljs.github.io/docs/UsersGuide.html#_language_support but I guess I'll make a note there too
Thanks for the clarification :thumbsup: @thheller
What is the easiest way to require and instrument spec namespaces/functions in development mode?
set the spec ns as a preload?
then call (s/instrument)
at the bottom of that ns/top-level?
the trouble with instrument
is that it is a macro and only instruments things that have been compiled by the type it is called
so if you put it in a preload that ns
also needs to require all namespaced its supposed to instrument
I think I can do that here… It does mean the specs won’t be in my app at all; but I’m keeping the namespaces separate right now, so they need to be included at the root.
if you are on a recent version you can get fancy and do
(def ^:dev/after-load instrument-everything []
(js/cljs-eval "(cljs.spec.alpha/instrument)"))
or maybe
(def ^:dev/after-load-async instrument-everything [done]
(-> (js/cljs-eval "(cljs.spec.alpha/instrument)")
(.then done)))
I also added :build-options {:auto-require-suffixes #{"-spec"}}
that will automatically add foo.bar-spec
to the build if foo.bar
is required
Thanks… I seem to be getting an error: “Use of undeclared Var cljs.spec.alpha/instrument”.
I have (:require [cljs.spec.alpha :as s :include-macros true])
in my ns definition
currently calling (s/instrument)
at the top level
you can also do (js/cljs-eval "(require 'cljs.spec.test.alpha) (cljs.spec.test.alpha/instrument)")
of course
yeah you’re right — I thought it was wrong; but had seen something online listing it that way
why cljs-eval
it?
why cljs-eval
both like you have, rather than via preload?
(If I only want them in dev mode)
you can do the preload that is fine. if you setup your requires correctly that will work just fine
it will only do stuff it knows about at the time it is compiled. so it is easy to miss stuff if you don't list something or so.
by using cljs-eval
it is ensured that the macro is expanded at a time where all other compilation has finished
I do think that the :preloads
variant is better and probably more reliable but it is more work and easy to mess up
Yeah ok, that’s more or less what I was thinking… Essentially you’re saying the fdef’s all need to be explicitly required for them to be found, from the top of this ns, so any fdef’s required from the app’s top level would be missed.
the fdefs need to be compiled before instrument is called yes, where from exactly doesn't really matter as long as its before
:thumbsup:
<preload-ns>
->
-> main.app-spec
is fine but for example won't invalidate <preload-ns>
when main.app-spec
is changed and as such won't affect instrument
I should really write this down somewhere. feel like I explained this before somewhere
what about where my.app.specs
->
?
hmm? obvioulsy need to have my.app.specs
required somewhere. if you do that in the preload that is fine, or the :auto-require-suffixes
I mentioned
yeah was thinking essentially it would just be required via the :preloads
would I need any :dev/always
or similar flags?
if you have a instrument call in that namespace yes. otherwise while editing the
code it will become "unstrumented". eg. watch compiles http://my.app and loads it so your
fdef instrument is replaced
ahh gotcha
makes sense
hmm I might well switch to using :auto-require-suffixes
stuff after all… will see :thinking_face:
yeah but including with ^:dev/after-load-async
does right?
it should in theory yes. never actually tried it 😛 frankly the instrument macro scares me 😛
I’m recreating react material ui docs in workbooks to prove my colleagues it’s not impossibly hard. I got pretty far in one go, but ended up shutting down my computer before finishing. After I got back I was faced with a weird situation where on initial load the cards are empty but after live reload they work. The problem seems to be with my importing. I’m trying to recreate
import {
MuiPickersUtilsProvider,
KeyboardTimePicker,
KeyboardDatePicker,
} from '@material-ui/pickers';
with
(ns app.mui-component (:require ["@material-ui/pickers" :refer [MuiPickersUtilsProvider KeyboardTimePicker KeyboardDatePicker]]))
having npm installed
"@material-ui/pickers": "^3.2.10",
but end up with
shadow-cljs - failed to load module$node_modules$$material_ui$pickers$dist$material_ui_pickers
shadow.js.jsRequire @ js.js:74
shadow.js.require @ js.js:113
eval @ app.mui_components.js:10
goog.globalEval @ main.js:577
env.evalLoad @ main.js:1670
(anonymous) @ main.js:2650
main.js:1672 An error occurred when loading app.mui_components.js
env.evalLoad @ main.js:1672
(anonymous) @ main.js:2650
main.js:1673 undefined
env.evalLoad @ main.js:1673
(anonymous) @ main.js:2650
Any tips on what to check/try/read?are there more errors? there should be. its just telling you what failed to load, the why you didn't paste?
I cannot tell what the actual error is either. my guess would be that maybe it expects a different react version?
“buch of other stuff” you mean errors? If I comment out the
@material-ui/pickers
import and defs/cards/componests that end up relying on something undefined, I get no errors. When I remove the comments it’s like the whole namespace doesn’t loadreact-dom.development.js:89 Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See for details.
* Move data fetching code or side effects to componentDidUpdate.
* If you're updating state whenever props change, refactor your code to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at:
* Rename componentWillReceiveProps to UNSAFE_componentWillReceiveProps to suppress this warning in non-strict mode. In React 17.x, only the UNSAFE_ name will work. To rename all deprecated lifecycles to their new names, you can run `npx react-codemod rename-unsafe-lifecycles` in your project source folder.
Please update the following components: ReactGridLayout, ResponsiveReactGridLayout
I get that warning with and without pickers. I thought it was a Fulcro thing but I’ll try to make sure
I’m sorry to let you know that it is working again, but I don’t know why. I’ll try to break it again for a while but will then move on. Thanks the replys!
@thheller I'm still having trouble compiling the file:
[:main] Build failure:
Closure compilation failed with 2 errors
--- kr/models/ronde-tempel-compiled.js:7
Requested module does not have an export "createElement".
--- kr/models/ronde-tempel-compiled.js:7
Requested module does not have an export "useRef".
Now watch
build works again, but having minification issues I think, for release
cannot read property 'geometry' of undefined
;;probably for
createElement("mesh", {
material: materials.red,
receiveShadow: true,
castShadow: true,
geometry: nodes.temple_railing_top.geometry,
name: "temple_railing_top",
position: [0.82, 2.23, -2.03],
rotation: [Math.PI, 0, Math.PI],
scale: [2.61, 2.61, 2.61]
})
say, I have two custom node libraries, depending on conflicting versions of d3
. By default, shadow
would try to resolve a single d3 version. :js-options :resolve
doesn't help here either, because it just lets me choose the d3 version to resolve, correct? How to best deal with this? Should I use rollup to package the two libraries?
@bbss if you use require
and module.exports
instead of import/export
the file is treated as commonjs and as such does not go through :advanced
JS code otherwise doesn't have externs inference so you could just add externs manually as well
@bendlas shadow-cljs will not let you include 2 different versions of d3 no matter what so you have to use something different to get that yes
https://code.thheller.com/blog/shadow-cljs/2020/05/08/how-about-webpack-now.html maybe the :js-provider :external
How do I run the browser tests once they are generated? I am having difficulties figuring this out from the documentation
the :browser-test
build is meant to be opened in a browser. it should generate an html file as part of its output that you can open
How do you open it?
here’s an example of our config for it:
:test {:target :browser-test
:test-dir "resources/public/test"
:ns-regexp "-test$"
:compiler-options {:language-in :es6
:output-feature-set :es6}
:devtools {:http-port 8021
:http-root "resources/public/test"}}
so I would go to http://localhost:8021/
hmm. I get a bunch of errors when I do shadow-cljs watch test
Okay smaller library trying this out works. But I don’t see the results of the tests. Where are they printed?
I have this in the console. env.cljs:187 error when calling lifecycle function shadow.test.browser/start Error: Assert failed: cljs-test-display: Element with id "test-root" does not exist.
Okay that worked
Seems that this needs to be generated with the file.
Yea I just tried on another project and it generated things properly. :man-shrugging:
I’ve literally been going down a rabbit hole trying to figure out why the test runner wasn’t working with Kaocha. Tracing problems in the code but it was actually the runner. shadow-cljs to the rescue again 🙇
I just ran into a problem, where I'm not sure if it's about shadow or the closure compiler:
A node module, accessing process
, hence triggering shadow's automatic require('process')
, got moved by the closure compiler into a common base module, where it then failed to require process
. But only in production mode.
yes, the js require had been rewritten to a shadow require at that point, but the module wasn't found. I suspect that, since the require('process')
is added by shadow, it might have added the shadow$provide
for process
too late, because it didn't know about the require being cross-module moved, or something. If it's not obvious to you from the description, I can try to condense a test case ....
Hi, is this guide still up-to-date: https://code.thheller.com/blog/shadow-cljs/2019/03/03/code-splitting-clojurescript.html? If I want to split a large component in my Re-frame app into a separate module, I will add events, subscriptions and views namespaces into this module and load view by lazy-load as in the example? How do I load subscriptions and events namespaces? Should I add them to the main view namespace?