ClojureScript with React Native
We are coming up on half a year since React Native was announced, and I wanted to share a rundown of the state of ClojureScript with React Native.
React Native is known to work with Om and with Reagent without changing either of those libraries. So, you could conceivably build and ship an app today using those stacks. In fact, the QTTT demo binary is running in appetize.io.
But, there are some affordances that are being built into ClojureScript's tooling that will make it easier to work with React Native. The demos above are built using React Native's packager. The ClojureScript tooling enhancements will make it easier to directly consume React Native's JavaScript libraries—which make use of CommonJS and JSX—without involving use of an external packager.
With respect to CommonJS processing, as a part of her GSoC project, Maria Neise has landed support in both ClojureScript and in the Google Closure Compiler. Maria's blog is a great resource for the details on this front. At the high level, things work, but some things in React Native, for lack of a better technical term, “trip things up.” These range from little things like CLJS-1319, to perhaps more challenging scenarios like CLJS-1312.
Even with CommonJS support, we need a :foreign-libs spec for React Native. I've played around with what it might mean to produce one in an automated fashion with дерево. This results in a spec with entries like
{:file "react-native/Libraries/ActionSheetIOS/ActionSheetIOS.js",
:provides ["ActionSheetIOS"],
:module-type :commonjs}
A :foreign-libs spec for React Native is hundreds of lines long, so this is definitely an area that needs automation! My hope is that something like this gets sorted out, and can live in a library maintained at CLJSJS.
With respect to JSX, the idea is to be able to generically plug in transforms (see CLJS-1177). Facebook has a tool that can convert JSX to plain vanilla, and they've also recently announced a switch to a new tool named Babel that will do the same.
With respect to Ambly, the Ambly wiki has a “quick start” explaining how to get up and running with React Native and Om using the packager, but to use the new CommonJS support there is an odd twist with the loading sequence, and a potential long-term solution may be CLJS-1313, or something like it.
With respect to React Native for Android, Ambly is ready for use from Windows and Linux, and some design exists in the Ambly wiki for directly supporting Android. (Part of this design depends on whether React Native uses JavaScriptCore on Android.)
I think it's awesome where we are. This stuff is fascinating! If you'd like to help, hopefully the above gives you a feel for where you could potentially contribute if you are so inclined! Contributions for this stuff range from simply trying stuff out to find where it breaks, to even contributing to the compiler with fixes.