Discussion: Integrate boot to avoid fragmentation about re-natal

[vikeri]

Same issue in boot-react-native: mjmeintjes/boot-react-native#48

[tiye]

I'm voting for Boot too. My toolchains has bugs in figwheel bhauman/lein-figwheel#399 so I really hope there's a Boot solution I can use.

[arichiardi]

It would be great, boot is way better at programmatically adding files to the classpath and potentially solve the already fragmented world of js dependencies (Webpack, CommomJS, ...).
What is to be done?

[drapanjanas]

This is a good discussion. I have not uesd boot yet, but I have quite hight it on my "try/learn" list.
Though I am not too convinced that same CLI tool like re-natal should support workflow with both build tools. I would rather prefer to have a separate CLI for example boot-natal (you name it) and implement something what is needed for the workflow with boot but outside of project build tasks. In that sense I see no clear benefits of actually merging boot-react-native with re-natal. Maybe we could build something like natal/re-natal CLI to generate boot-react-native templates?
My arguments for not mixing up lein and boot in same CLI tool:

1. re-natal is very specific to development workflow with figwheel (and therefore lein), so many of commands would not make sense for boot project I guess, as probably same could be implemented as build tasks
2. I think the templates would be a bit different with boot from those currently generated, like files in env/ sources which are figwheel specific
3. If implementation is not designed right, re-natal will be way more complex and require be more work to maintain and extend (so noone would do it and it would just die)

It is not very clear to me what boot-react-native does not have compared to re-natal. Is it only the initial project generation for different react wrappers? Otherwise it seems more less same, no? Re-natal is actually more hacky solution (in respect to React Native) because it bypass the packager via figwheel.

[vikeri]

Good points, maybe they should be different cli tools but share a library where things in common can be found:

• Templates (excluding figwheel specific things, a lot of cljs stuff should probably be similar right?)
• Smart stuff like xcode, use-ios-device etc
• The cljs compiler settings
• Other RN tooling that will be needed in the future

I'm just feeling that since we are such a small community it is a shame that people are solving the same issue in various places. Being small gives us the opportunity to think things through and build a good modular core that ensures a common foundation while allowing for modular extensions (boot/lein, om/reagent etc.). Not sure if this is the way to go, I have limited insight in boot for example, but I believe these things ought to be pondered at least 😄

I tried boot-react-native at first but I couldn't get things working so I switched to re-natal which has been a superior experience for me so far.

[pesterhazy]

We've been using boot-react-native since its beginning, and after a few rough weeks in the beginning it's working very well for us. The approach of using the RN packager is very powerful, as there is a very similar environments for debug ("online" bundle) and release ("offline" bundle).

We also have a "one click" workflow, where running boot dev --platform ios does a lot of things:

• update dependencies (like npm)
• start cljs compilation
• compile the objc code without opening xcode
• open the simulator and run the app
• tail the simulator log file so you get log messages in boot's output

Additionally of course also there's automatic reloading of code. You can also just require npm dependencies, and they'll automatically get picked up. Everything reloads in 2 seconds or less. I think this interactivity is very important.

I've also felt that it's unfortunate that there's a split between re-natal and boot-react-native, and would be happy to help joining the efforts.

[vikeri]

@pesterhazy Alright good to hear. What are your thoughts on at least unifying some common elements of the two libraries?

In general I sort of got the feeling that boot-react-native was semi-abandoned? RN is moving at a fast pace and boot-react-native has not been updated in a while. @drapanjanas has been doing a great job of maintaining the pace.

[pesterhazy]

@vikeri I'd like to help get b-r-n updated in the new future. I certainly haven't abandoned it, though I agree that code and docs badly need a fresh code of paint.

Which parts do you think could be unified? I'd certainly like to see more wrappers for r-n js libraries in cljs, but those should work for either project.

[vikeri]

@pesterhazy: I've understood from slack that it is still under development and that you are using it, awesome! Yeah, since it is a fairly new project for a completely new thing, docs seem quite important. Basically the things I mentioned in #53 (comment)

Off topic: Very confusing that you have different avatars on slack and github 😉

[vikeri]

I've now create an (eventually) agnostic lib where we could put some common tools: https://github.com/vikeri/rn-cljs-tools

I wrote it in bash but it might be better to have it writte in js for example so then one may use it with npm install -g.