This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-17
Channels
- # beginners (45)
- # boot (33)
- # chestnut (9)
- # cider (2)
- # cljs-dev (24)
- # cljsrn (1)
- # clojure (114)
- # clojure-conj (3)
- # clojure-dev (3)
- # clojure-dusseldorf (3)
- # clojure-greece (5)
- # clojure-italy (22)
- # clojure-russia (10)
- # clojure-spec (12)
- # clojure-uk (19)
- # clojurescript (117)
- # core-async (16)
- # cursive (3)
- # data-science (1)
- # datomic (5)
- # docs (13)
- # emacs (1)
- # fulcro (13)
- # graphql (1)
- # hoplon (20)
- # immutant (3)
- # jobs (1)
- # juxt (12)
- # lein-figwheel (1)
- # luminus (4)
- # off-topic (12)
- # onyx (61)
- # portkey (1)
- # re-frame (21)
- # reagent (26)
- # ring-swagger (38)
- # rum (1)
- # shadow-cljs (222)
- # slack-help (4)
- # spacemacs (11)
- # specter (67)
- # uncomplicate (236)
@thheller I think I have narrowed this down. when :lein true
is set, shadow-cljs npm-deps
does not appear to install transitive deps. I’ve pushed the config to /website
in re-view: https://github.com/braintripping/re-view.git
In the repo, :source-paths
in shadow-cljs.edn
is identical to :source-paths
in project.clj
, but commented out. I would expect there to be no difference between where :source-paths
are specified when using :lein true
. but if I run shadow-cljs npm-deps
without specifying the deps in shadow-cljs.edn, they do not install.
if I uncomment :source-paths
in shadow-cljs.edn, then it works. (even if I keep :lein true
)
oh, yes. npm-deps
does not use lein
, so it doesn’t pickup the dependencies of that, since no :dependencies
are listed in shadow-cljs.edn
how come you are sticking to lein
? just because of the cursive integration or some other reasons?
checkouts is also a minor thing. now i am switching to only source-paths, but then I have to remember to add :dependencies manually
Colin said he is going to add support for deps.edn
soon, when that comes I can take advantage of that too
so, I think it should work now without any lein install
-ing, to try shadow-cljs release browser
in re_view/website, and you can observe that if componentDidUpdate
is not listed in browser.txt
, the build breaks. I am not sure why it is not being included in the auto externs
yarn
is enough since they are in there already https://github.com/braintripping/re-view/blob/master/website/package.json
so i assume if you run shadow-cljs server
and open the page, it will load fine. but if you comment componentDidUpdate
in externs/browser.txt and build again, then there is an externs error
so in target/shadow-cljs/builds/browser/release/externs.shadow.js
I don’t see any lifecycle methods, but I do see isPureReactComponent
, isValidElement
, other React things
'use strict';
if (process.env.NODE_ENV === 'production') {
module.exports = require('./cjs/react.production.min.js');
} else {
module.exports = require('./cjs/react.development.js');
}
I hesitate to draw conclusions yet, because I don’t know why or if something is wrong somewhere 😉, but the shadow-cljs advanced build using these direct node_modules requires vs. my old webpack stuff has led to a smaller build, 950kb vs 1.4mb
if (typeof instance.componentWillReceiveProps === 'function' && (oldProps !== newProps || oldContext !== newContext)) {
callComponentWillReceiveProps(workInProgress, instance, newProps, newContext);
}
separately: in re_view/src/
the deps.cljs includes some :externs… are these not being picked up?
re: earlier comment about react - do you mean that in this current advanced build, react + react-dom are being included twice?
hmm yeah thats really a problem I need to solve, the problem really is that you are not supposed to include those externs
yes, react will be included twice. but release will remove the dev version so its not a big deal in release.
so even for this it would make sense to have a way to map from npm module names to externs files, that way there isn’t duplication
then if multiple projects would declare them, one could de-dupe, without needing a global registry that is maintained
hmm where do you use componentDidUpdate
? maybe we can solve this by annotating the code?
(fn [^react/SyntheticEvent e]
I don’t think that is valid? should start with ^js/
? i think
but for shadow-cljs all that matters is the ^js
tag anyways, the type info is optional
so is it possible to annotate that e
is an instance of my-referred-react-thing.SyntheticEvent
(def kmap
"Mapping of convenience keys to React lifecycle method keys."
{:constructor "constructor"
:view/initial-state "$initialState"
:view/state "$state"
:view/did-catch "componentDidCatch"
:view/will-mount "componentWillMount"
:view/did-mount "componentDidMount"
:view/will-receive-props "componentWillReceiveProps"
:view/will-receive-state "componentWillReceiveState"
:view/should-update "shouldComponentUpdate"
:view/will-update "componentWillUpdate"
:view/did-update "componentDidUpdate"
:view/will-unmount "componentWillUnmount"
:view/render "render"})
source-mapping is taking me all over the place but seems nowhere near the actual source of .componentDidUpdate
in the javascript source near the error, one can see get-element
and other things that make me believe it’s L#100 of that file. plus it is the only place in the project that uses .componentDidUpdate
as a host interop call
i remember now the macro stuff i was thinking of. i allow views to have custom methods included in the map, like {:my-method ...}
, the macro writes these in host interop syntax so that you can use them like (.myMethod the-component)
and closure will rewrite it all and it will still work, without any annotations.
but all the :view/*
stuff goes through that kmap
you saw and is never rewritten with host interop syntax
if i move the ^js annotation into the arglist, it seems to work:
(fn [{:keys [view/state get-element] :as ^js this}]
...
(.componentDidUpdate this))
`can’t say I have ever understood exactly where these annotations are allowed to go. i recall quite a bit of trial and error when i first added them.
but this is good, adding ^js
there in the arglist fixes the .componentDidUpdate
call and I tried adding a custom method to the component and calling it in the same place, also worked.
-> Babel transform: node_modules/@material/animation/index.js
<- Babel transform: node_modules/@material/animation/index.js (629 ms)
-> Babel transform: node_modules/@material/base/foundation.js
<- Babel transform: node_modules/@material/base/foundation.js (34 ms)
-> Babel transform: node_modules/@material/base/component.js
<- Babel transform: node_modules/@material/base/component.js (59 ms)
-> Babel transform: node_modules/@material/ripple/adapter.js
<- Babel transform: node_modules/@material/ripple/adapter.js (17 ms)
-> Babel transform: node_modules/@material/ripple/constants.js
<- Babel transform: node_modules/@material/ripple/constants.js (13 ms)
-> Babel transform: node_modules/@material/ripple/util.js
<- Babel transform: node_modules/@material/ripple/util.js (44 ms)
-> Babel transform: node_modules/@material/ripple/foundation.js
<- Babel transform: node_modules/@material/ripple/foundation.js (172 ms)
-> Babel transform: node_modules/@material/ripple/index.js
<- Babel transform: node_modules/@material/ripple/index.js (48 ms)
-> Babel transform: node_modules/@material/selection-control/index.js
<- Babel transform: node_modules/@material/selection-control/index.js (9 ms)
-> Babel transform: node_modules/@material/checkbox/adapter.js
<- Babel transform: node_modules/@material/checkbox/adapter.js (12 ms)
-> Babel transform: node_modules/@material/checkbox/constants.js
<- Babel transform: node_modules/@material/checkbox/constants.js (6 ms)
-> Babel transform: node_modules/@material/checkbox/foundation.js
<- Babel transform: node_modules/@material/checkbox/foundation.js (68 ms)
-> Babel transform: node_modules/@material/checkbox/index.js
<- Babel transform: node_modules/@material/checkbox/index.js (55 ms)
first one is always slow since it has to spin up the node process but after that its pretty smooth
just pushed [email protected]
re-view website [:browser] Build completed. (334 files, 233 compiled, 0 warnings, 22.40s)
down from 47sec
and we are about the same size with slightly better performance characteristics since not everything is wrapped into one big IIFE
in ./editor, I have 2.0.22 in package.json, but when I run shadow-cljs server
I see
mattpro:editor MattPro$ shadow-cljs server
shadow-cljs - config: /Users/MattPro/Documents/sites2017/maria/editor/shadow-cljs.edn version: 2.0.7
yeah, now unless I use yarn run ...
it appears to use my old global version instead of local npm version
I changed the way the package is bundled, the old one doesn’t pick that up correctly
the shadow-cljs
script checks for <project>/node_modules/shadow-cljs/cli/lib.js
which doesn’t exist anymore
thinking it might be better to just recommend using npx shadow-cljs
or yarn shadow-cljs
to run things
we are at a point where the install really must be in the project, it was sort of optional before
https://github.com/mhuebert/maria/blob/master/editor/package.json#L7 could be removed
you might consider getting rid of the :trusted
build and just code-split the :live
build. there might be tons of overlap … nevermind you are on two domains, so no sharing
also (enable-console-print!)
is never required, shadow-cljs
injects that so you don’t have to 😉
yeah, the :trusted
build can be advanced compiled, whereas the :live
build uses selfhost and so must remain :simple
.
when I run npm-deps
I am seeing:
[:npm-deps-conflict "codemirror" :using :a]
[:a "5.30.0" #object[java.net.URL 0x7f3a9c11 "file:/Users/MattPro/Documents/sites2017/lark/tools/src/deps.cljs"]]
[:b "5.30.0" #object[java.net.URL 0x7f888518 "jar:file:/Users/MattPro/.m2/repository/lark/tools/0.1.5/tools-0.1.5.jar!/deps.cljs"]]
I think because I am using these extra source-paths in lieu of checkouts