This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-07-18
Channels
- # aleph (4)
- # beginners (70)
- # cider (66)
- # clara (16)
- # cljdoc (20)
- # cljs-dev (9)
- # cljsrn (2)
- # clojure (36)
- # clojure-ecuador (2)
- # clojure-italy (14)
- # clojure-japan (2)
- # clojure-nl (22)
- # clojure-uk (79)
- # clojurescript (133)
- # clojutre (2)
- # code-reviews (5)
- # cursive (5)
- # data-science (1)
- # datomic (47)
- # duct (2)
- # emacs (1)
- # figwheel-main (3)
- # fulcro (11)
- # funcool (1)
- # graphql (6)
- # hyperfiddle (4)
- # leiningen (4)
- # luminus (9)
- # lumo (8)
- # mount (4)
- # nrepl (2)
- # off-topic (19)
- # onyx (1)
- # re-frame (23)
- # reagent (91)
- # reitit (17)
- # ring-swagger (2)
- # shadow-cljs (43)
- # tools-deps (27)
- # vim (45)
Is there a way to decrease the size of an app built and served by shadow-cljs in dev mode? We’re only a few pages into our app and the payload in dev is already over 15MB - well over half of that is cljs core and uncompressed 3rd party deps. There’s also an issue regarding the sheer number of http requests required to deliver code this way, I’m seeing hundreds of requests for the category of code described above, this makes testing on a mobile or in browser emulation tools very slow
@tomi.hukkalainen_slac I don’t believe that is recommended in development for compilation time reasons
Testing and pure development are a bit different, so it might be better still to do even :simple for those mobile test runs
@tomi.hukkalainen_slac That’s a fair point, not ideal but a workaround that I can live with
When starting an embedded shadow-cljs from clj
(with a deps.edn
only containing the dep on shadow 2.4.20), the :source-paths in shadow-cljs.edn
seems to be totally ignored. Can I convince the embedded shadow to use the source paths in shadow-cljs.edn instead? I tried :deps false
without success. (I can setup an alias in deps.edn, but I’d rather have the cljs stuff in the shadow config and the clj stuff in deps.edn)
Related to nijk's question, is there a nice way to analyze/visualize the shadow bundle content sizes, similar to https://chrisbateman.github.io/webpack-visualizer/ or https://github.com/webpack-contrib/webpack-bundle-analyzer
@tomi.hukkalainen_slac answer is yes, how, I forgot. Start the server and type some command. Sure someone here will tell you. There’s I think a blog post from thheller on how to do it.
That last comment shows the same report I get with https://shadow-cljs.github.io/docs/UsersGuide.html#_build_report so I guess no pretty graphs for now, unless I build it myself.
@thheller I was offline for 2 days
Back to the issue that I have with aws-sdk
Here is my error:
➜ shadow-cljs-app git:(master) ✗ shadow-cljs watch browser
shadow-cljs - config: /Users/viebel/prj/shadow-cljs-app/shadow-cljs.edn cli version: 2.4.5 node: v10.6.0
shadow-cljs - updating dependencies
shadow-cljs - dependencies updated
shadow-cljs - starting ...
[2018-07-18 17:02:28 - WARNING] TCP Port 9630 in use.
[2018-07-18 17:02:34 - WARNING] failed to start :browser dev-http:8025 reason: java.net.BindException: Address already in use
shadow-cljs - HTTP server for :browser available at
shadow-cljs - server version: 2.4.5
shadow-cljs - server running at
shadow-cljs - socket REPL running on port 49168
shadow-cljs - nREPL server running on port 49170
shadow-cljs - watching build :browser
[:browser] Configuring build.
[:browser] Compiling ...
[:browser] Build failure:
The required JS dependency "util" is not available, it was required by "node_modules/aws-sdk/lib/event_listeners.js".
Searched in:/Users/viebel/prj/shadow-cljs-app/node_modules
You probably need to run:
npm install util
See:
I have created a public github repo that reproduces this issue. Here it is: https://github.com/viebel/shadow-cljs-app
@viebel you need to add shadow-cljs
itself as a npm dep. npm install --save-dev shadow-cljs
that will install the missing util
polyfill
Awesome. It worked. I missed this part in the documentation
@nick828 I'd look into trying to reduce the deps a bit. 15mb is a bit excessive and will still probably be huge in :advanced
release builds. beyond that gzip + http2 can help reduce load times in dev
@niclasnilsson shadow-cljs
completely relies on the JVM classpath so whatever you use to manage that is responsible for including the source paths. shadow-cljs can't add any paths after startup.
@thheller Ah, ok. Thanks!
@tomi.hukkalainen_slac I played with various visualizations but none of them were even close to the simple table view in actual visible information
Hello, first time user of shadow-cljs and trying to run the “conduit” example from the main repo (as it matches as close as possible what I need to do) to adapt my workflow to it. Everything yet works, except that if I change the source code (of a reagent component from the demo), shadow-cljs says that it compiled without errors, the browser then tries to reload it, but then throws an error in its console:
env.cljs:174 error when calling lifecycle function conduit.core/main Error: Target container is not a DOM element.
at module.exports (invariant.js:43)
at legacyRenderSubtreeIntoContainer (react-dom.development.js:17239)
at Object.render (react-dom.development.js:17318)
at Object.reagent$dom$render_comp [as render_comp] (dom.cljs:20)
at Function.reagent.dom.render.cljs$core$IFn$_invoke$arity$3 (dom.cljs:44)
at Function.reagent.dom.render.cljs$core$IFn$_invoke$arity$2 (dom.cljs:39)
at Function.reagent.core.render.cljs$core$IFn$_invoke$arity$2 (core.cljs:74)
at conduit$core$main (core.cljs:75)
at shadow.cljs.devtools.client.env.make_task_fn (env.cljs:171)
at shadow$cljs$devtools$client$env$do_js_reload_STAR_ (env.cljs:180)
shadow.cljs.devtools.client.env.make_task_fn @ env.cljs:174
shadow$cljs$devtools$client$env$do_js_reload_STAR_ @ env.cljs:180
(anonymous) @ env.cljs:180
(anonymous) @ env.cljs:209
shadow$cljs$devtools$client$env$do_js_reload_STAR_ @ env.cljs:180
shadow.cljs.devtools.client.env.do_js_reload.cljs$core$IFn$_invoke$arity$4 @ env.cljs:216
shadow$cljs$devtools$client$browser$do_js_reload @ browser.cljs:66
(anonymous) @ browser.cljs:151
(anonymous) @ browser.cljs:100
goog.events.EventTarget.fireListeners @ goog.events.eventtarget.js:284
goog.events.EventTarget.dispatchEventInternal_ @ goog.events.eventtarget.js:381
goog.events.EventTarget.dispatchEvent @ goog.events.eventtarget.js:196
goog.net.XhrIo.onReadyStateChangeHelper_ @ goog.net.xhrio.js:867
goog.net.XhrIo.onReadyStateChangeEntryPoint_ @ goog.net.xhrio.js:813
goog.net.XhrIo.onReadyStateChange_ @ goog.net.xhrio.js:797
XMLHttpRequest.send (async)
goog.net.XhrIo.send @ goog.net.xhrio.js:627
goog.net.XhrIo.send @ goog.net.xhrio.js:352
shadow$cljs$devtools$client$browser$load_sources @ browser.cljs:92
shadow$cljs$devtools$client$browser$handle_build_complete @ browser.cljs:151
shadow$cljs$devtools$client$browser$handle_message @ browser.cljs:267
shadow$cljs$devtools$client$env$process_ws_msg @ env.cljs:148
(anonymous) @ browser.cljs:327
(I changed the dependency in the example source to use the latest 2.4.21 version of shadow-cljs)
With the “conduit” example I mean the example source from https://github.com/jacekschae/conduit
@eoliphant One coworker is playing with it, but not with shadow. I guess he has just a dist bundle with global assignment or something. Any particular problems?
I lost interested after he told me you need to run your separate less build anyway to change the style. So I went for material-uiV1 instead (from V0)
MUI got a lot of flak from being difficult to customize, but I think their choice to use JSS is the best one, from the modern options I'm aware of
ill check it out. i’m more of a backend guy. so i tend towards stuff that gets most of the way there, then someone else can come theme , etc
now i’m looking at MUI agian.. looks prety cool. especially the pro thanks for confusing me lol lol..