This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-05-03
Channels
- # aws (6)
- # babashka (77)
- # beginners (102)
- # clj-kondo (24)
- # cljsrn (17)
- # clojure (40)
- # clojure-australia (15)
- # clojure-europe (50)
- # clojure-nl (4)
- # clojure-uk (4)
- # clojurescript (9)
- # conjure (2)
- # cursive (28)
- # data-science (1)
- # datomic (21)
- # events (5)
- # joker (15)
- # malli (136)
- # meander (1)
- # off-topic (25)
- # pathom (4)
- # podcasts-discuss (2)
- # portal (12)
- # portkey (1)
- # powderkeg (1)
- # practicalli (5)
- # re-frame (14)
- # reitit (3)
- # shadow-cljs (49)
- # specter (4)
- # tools-deps (4)
- # unrepl (1)
@thheller I was thinking a bit more about the approach in https://github.com/thheller/reagent-react-native with react-native/metro separated into a subdirectory. You specifically said "CLJS tooling related things" go in the top-level package.json. Is it accurate that that conflicts a bit with the default behaviour {:npm-deps {:install true}}
which installs non-tooling JS deps in the top-level package.json / node_modules, instead of the one in react-native/, where metro in the end looks for it? One might end up with different versions of the same package in the two node_modules directories.
that is correct yes. I'll likely remove the automatic :npm-deps
install completely at some point and make it a proper manual command instead
but the duplicate install won't be used under normal circumstances so it doesn't matter too much for now
also you don't have to do this separation. it just made sense to me. I also don't actually use react-native for anything so I might be totally wrong
I like the separation very much, I was delighted when I found that example! There's so many files in a react-native project, all on the top level, that just come straight from the react native template. I like a cleaner workspace.
Thanks! Then I'll set {:npm-deps {:install false}}
and go with that one right away.
I briefly tried debugging though and it didn't find the CLJS source. I suspect that that has to do with the fact that the CLJS source files are outside of the metro / react native root, but I didn't have time yet to look into that.
who didn't find cljs sources? metro shouldn't care, it should only see the sources generated in that dir https://github.com/thheller/reagent-react-native/blob/master/shadow-cljs.edn#L14
But as I said, I just stumbled over this and haven't had a moment to confirm or disprove that shallow hypothesis
My app is surprisingly large in release mode.
I used shadow-cljs release app
on my reagent/reframe app. the js folder that is created is 25MB. do I need to manually delete the cljs-runtime folder?
@merklefabian try deleting the output folder before doing release app. Most of the big stuff in there is only needed for the development build.
is it still possible to 'hack' on shadow-cljs by adding the lib to the classpath? i've added it to src/
and i get conflicts on compile so i assume it is being added to the cp. unfortunately i don't see changes i've made to the codebase, or see any hot reloads when i change cljs files
@biscuitpants I'm not sure I understand the question. what did you add to src
? replacing shadow-cljs internal namespace should be fine yes?
if you are using shadow-cljs.edn
only (no deps.edn, project.clj) you might need to add :aot false
to the top level
yeah i've got src/shadow/cljs/ui/components/inspect.cljs
and just added a simple prn
to ui-tap-panel
and it doesn't seem to be overwriting the default inpsect.cljs
i'm using shadow-cljs.edn
with deps.edn
and :deps true
well that explains it š
thanks for the help š
yeah that is what i'm going to do
fwiw i'm trying to add js/Object
support to inspect
hmm i'll double check my versions, but doing tap>
on a pure JS object just printed js/Object
ah. i'll dig more through the code then. definitely missed something
https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/remote/runtime/obj_support.cljc
thank you
you can extend the Datafiable protocol onto any objects in your codebase and it'll just work in the UI
ahhh that is much easier! i did not know that. thank you
really nice way to do that
there are some more examples here https://github.com/thheller/shadow-experiments/blob/master/src/main/shadow/experiments/grove/dev_support.cljs
ahh that's awesome. very useful for custom objects
really useful for react/other components
Hello @thheller looking at this guy https://github.com/thheller/shadow-cljs/issues/434#issuecomment-461206429 It looks like that this means that
:js-options
{:source-map false}
would prevent source maps from things inside of node_modules
from being outputted?https://imgur.com/a/StHAnXP ā¦ the only difference with these is that the smaller one has
:js-options
{:source-map false}
set.
https://github.com/thheller/shadow-cljs/blob/ba0a02aec050c6bc8db1932916009400f99d3cce/src/main/shadow/build/api.clj#L125`default-js-options`https://github.com/thheller/shadow-cljs/blob/ba0a02aec050c6bc8db1932916009400f99d3cce/src/main/shadow/build/api.clj#L125Is there an easy way to "re-export" a variable from a js libary using the same name? For example, instead of having to say:
(ns xxx
(:require ["my-lib/my-thing-1" :default my-thing-1*]))
(def my-thing-1 my-thing-1*)
for every my-thing-n
, is there a way similar to (:require ["my-lib/my-thing-1" :default my-thing-1* :reexport)
, so that I can use xxx/my-thing-1
in another ns in the same project?