Clojurians Log v2

@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

I mean the original CLJS for source-mapping during debugging

But as I said, I just stumbled over this and haven't had a moment to confirm or disprove that shallow hypothesis

does react-native finally support source maps? been a while since I checked

source maps otherwise are self contained and contain all sources

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.

the cljs-runtime folder is not used by release builds yes

Thanks for your quick answer. Whats the reason it is not deleted automatically?

shadow-cljs doesn't delete stuff as sort of a rule 😛

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

you can't hack the cljs parts that way

those are precompiled and only the finished JS files is used

ahhh

well that explains it 😄

thanks for the help 🙂

you can compile the UI code locally and replace it for your app if you want

yeah that is what i'm going to do

fwiw i'm trying to add js/Object support to inspect

that is already supported?

hmm i'll double check my versions, but doing tap> on a pure JS object just printed js/Object

for that you don't need to change the UI code at all btw

since that part is handled by the code that is injected into your app

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

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/remote/runtime/cljs/js_builtins.cljs

that would be the support for generic JS objects

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

can be handy to be able to look into "foreign" objects via the UI

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}

no, there is no separate setting for node_modules source maps

https://imgur.com/a/StHAnXP … the only difference with these is that the smaller one has

:js-options
{:source-map false}

hmm kinda accidental that this works then I guess

Is 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*)