cljsrn

https://github.com/drapanjanas/re-natal | https://github.com/drapanjanas/re-natal/wiki/FAQ | https://github.com/condense/mercury-app/wiki | https://github.com/seantempesta/expo-cljs-template/ https://www.npmjs.com/package/create-expo-cljs-app
dotemacs 2020-12-20T19:10:00.251100Z

I guess it’s all about trade-offs: if what you need to do is supported by the libraries that are Expo compatible, cool. But if you need to leverage third party libraries that aren’t Expo compatible, then you can go via “native” react-native.

bringe 2020-12-20T20:56:02.256Z

In my case, I'm learning RN (and how to use cljs with it), and I also am somewhat prototyping an app for a company that I'm almost positive needs things that would require ejecting from Expo. I think an argument could be made for using Expo either just for the prototype or for the actual app until those features come up. But my argument for going react native cli w/out expo is twofold: 1. I'm just now learning RN, and since I anticipate moving to react native cli / ejected expo in the future, I'd like to learn that way from the beginning so I'm already familiar with it 2. Expo seems like a great tool, and I haven't ruled it out completely for this case yet. However, no matter how easy it may be, I'd say it's not as simple as react-native cli. It's another layer on top of an already layered system. When something goes wrong, I want to know at least that it's not this added Expo layer causing some issue.

👍 2
bringe 2020-12-20T20:59:00.257800Z

I also feel that so far react-native cli doesn't seem like that much extra work, but again I'm new to all this so I think the extra work hasn't hit yet (obviously Expo is popular for a reason). I expect it to come more in cross-platform handling and deployment, but I think some of this stuff can be automated, and some is worth the extra effort + can be minimized with proper planning.