This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (55)
- # cider (22)
- # cljs-dev (123)
- # cljsrn (75)
- # clojars (1)
- # clojure (92)
- # clojure-europe (2)
- # clojure-italy (16)
- # clojure-nl (6)
- # clojure-spec (17)
- # clojure-uk (77)
- # clojured (2)
- # clojurescript (39)
- # core-async (8)
- # cursive (4)
- # data-science (1)
- # datomic (22)
- # duct (4)
- # editors (21)
- # emacs (10)
- # events (4)
- # fulcro (116)
- # graphql (8)
- # immutant (3)
- # jackdaw (1)
- # juxt (3)
- # kaocha (4)
- # luminus (1)
- # mount (1)
- # nrepl (32)
- # off-topic (34)
- # other-languages (5)
- # pedestal (32)
- # reagent (1)
- # ring (6)
- # ring-swagger (7)
- # shadow-cljs (5)
- # spacemacs (3)
- # specter (1)
- # sql (1)
- # vim (21)
hello everyone. I'm adding support for
shadow-cljs and could use some help testing things done by people that do actual
react-native development and know the platform. Support is already pretty good (I think) and less manual than
re-natal (I think) so all feedback is welcome. https://www.reddit.com/r/Clojure/comments/at8wkd/react_native_expo_with_shadowcljs/
only tried with
expo so far but I want plain
react-native support as well. I think everything should be setup to make that work already but I'm not sure
@thheller Great! Could you provide some brief motivations for why someone should switch from re-natal?
well the primary focus of
shadow-cljs has been to make life easier and integrate with
I want that to apply to
react-native builds as well. I have never done any
re-natal development but it seems to require working around a bunch of stuff and calling manual commands to use certain npm packages and stuff
I also heard that you can't use the latest react-native/expo version and are stuck on older ones? not sure if true but given that this requires zero hacks on the .js side a version upgrade is never a problem
Since the metro bundler solves the npm bundling that value is arguably less than for web browser when shadow-cljs seems like a huge improvement. Our main issues are (first commit in project March 2016): - Forgetting externs that then causes problems - Bundling with metro taking ages - Very hard to get sourcemaps to work for prod build (needs integration with metro)
so in the past I tried finding ways to work around
metro so that is doesn't process the generated CLJS output but it doesn't seem setup in a way that would allow that
Yeah, I was digging very deep into the metro bundler trying to get sourcemaps to work, but it wasn’t straightforward and I gave up when other stuff had to be done
The problem I had was that when I looked at it they had just switched to metro from RN Packager so the codebase was changing dramatically every release
there is this which makes it sounds like its primarily a performance problem https://github.com/facebook/metro/issues/104
So, they invented a new source-map format at facebook. Good for them. Explains why I had a hard time understanding it
create-react-app builds it is possible to supply a
.babelrc to ignore all generated code and skip its processing
ok it is used but completely bypassing the babel step doesn't work. so I guess one would just need to find the minimal set of babel plugins to run
What would be VERY nice that I think shadow-cljs is in a unique position to do is to bypass the entire metro-bundler for prod builds.
Compile the external libs with babel-react-native and then add the js wrapper that metro generates around the other code.
but yes I explored this approach before. let metro bundle all the JS stuff + assets and then merge the CLJS code into that after the fact
since I had to reverse engineer the client<->server interaction so I wouldn't do that again
Another hack could be to bundle everything with a simple js file that just requires all the deps and then in the final bundle replace the bundled js-file with the compiled cljs.
Nope, just marking the beginning of the js file with a
console.log("STARTFILE") and the end with
console.log("ENDFILE") and then just do a brute text replace of everything inbetween 😛
But the best way would be to support compile-to-js languages in metro. But since ReasonML compiles more straightforwardly to js they don’t need it and they already support flow and typescript natively in metro.
I still have no clue how this stuff actually ends up in the native app part since I have only used expo so far
my primary concern is that the more hacks you add the more things break in later versions
the approach I took will basically never break since it looks like normal .js to whatever metro/expo see
would be nice if there was a way to just create a babel preset that does nothing but process the source maps correctly
And with advancced compilation it doesn’t take too long to compile it even though babel goes over it
hmm I'll look at how the typescript support works. maybe something in there could be re-used.
Possibly, I’m afraid it might be similar to Reason though, one .ts -> one .js, and that is what metro seems to be optimized for.
Another cool idea would be to have a cpu heavy tool like this not be written in node. Would be interesting to see how fast it could be if it was written in Java, Rust, OCaml or similar.
ok but at least it seems possible to override the plugins used. so we just need one that handles source maps properly
That’s ideal, and then you cache the compilation of the npm deps with babel so you only have to compile cljs?
:advanced compiled build
also still using
yarn start. not the slightest clue how I'd make a release build with expo 😛
To make a release build with Expo, first create an account with them (free). Then run ‘expo login’ to store your credentials (only have to do this once). Once setup, to do a release just build your CLJS file first, then run ‘expo publish’. When it’s done, you can install the Expo app on your phone, login to your account, and you will see your app listed to run. I’m still working on porting everything over to shadow-cljs. Should be done later tonight or tomorrow (I have a couple of appointments today, not sure how productive the day will be). I’ll also report on the publish times, since I noticed they jumped dramatically from when I had a skeleton app (5 mins, maybe less) to where we are now, which takes about 25-30 minutes.
Ok, something very interesting would be to compare the build times for a bigger app like status: https://github.com/status-im/status-react
hmm I'm totally lost in that repo. there is no
package.json but there are both
project.clj. no idea how any of it works together. I'll check it out later if I find some time.
The package.json is in mobile_files dir because we also build for react-native-desktop with different deps
You can ping me as well if you have questions. Check the makefile if you are looking for an entry point. 'make prepare-android' for instance then 'make watch-android-avd' and 'make run-android' with an emulator running and you have a figwheel repl with hot reload.