hello everyone. I'm adding support for react-native in 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 npm

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 saw this https://anish-patil.blogspot.com/2019/02/getting-started-with-react-native.html

so none of the extra commands are required

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

eg. the demos were created by expo init ... which is the latest version I believe

I’m not using expo so I couldn’t testify to that

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

source maps I did not get to work properly either. again looks like a metro issue?

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

I haven't looked intro metro much. maybe there are options that would be useful?

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

Yes that’s exactly it!

So, they invented a new source-map format at facebook. Good for them. Explains why I had a hard time understanding it

in create-react-app builds it is possible to supply a .babelrc to ignore all generated code and skip its processing

not sure if that is also possible. not sure if babel is even used.

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.

That would be a dream come true

I don't think that is possible given their "ram" bundles and stuff

ram bundles?

https://facebook.github.io/metro/docs/en/bundling

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

https://clojureverse.org/t/exploring-react-native-expo-with-shadow-cljs/1969

that worked well to some extent but any update in the expo tools broke it

since I had to reverse engineer the client<->server interaction so I wouldn't do that again

Ok, that’s unfortunate.

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.

yeah that would be nice but is there a hook to do that?

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.

So I doubt fb will go through any effort to help us out there.

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

Yep that’s true

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

Totally

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.

haha

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.

that was easy

.babelrc in the app directory

{
    overrides:[
        { plugins: [] }
    ]
}

[10:54:47] Finished building JavaScript bundle in 5098ms.

Wooot!

That’s amazing.

hmm wait .. there has to be some cache involved somewhere

[10:58:28] Finished building JavaScript bundle in 1646ms. this can't be right

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?

hmm AFAICT the default behaviour is already good enough

once the cache is warm [11:20:44] Finished building JavaScript bundle in 1930ms.

For a prod build? That’s awesome

no dev build

Building JavaScript bundle: finished in 3281ms. consuming an :advanced compiled build

seems reasonable

but its just the basic test build I have setup which does basically nothing

not sure an actual app would take

also still using yarn start. not the slightest clue how I'd make a release build with expo 😛

Ok, something very interesting would be to compare the build times for a bigger app like status: https://github.com/status-im/status-react

ah good idea. I'll see if I can get that to build

hmm I'm totally lost in that repo. there is no package.json but there are both deps.edn and project.clj. no idea how any of it works together. I'll check it out later if I find some time.

Maybe @rasom or @andre could answer how to navigate the repo 🙂