Fork me on GitHub
#cljsrn
<
2017-05-28
>
pesterhazy09:05:38

actually I think we (cljs people) are in a great position today to come up with a better rn dev experience. Braindump of some of the things we could leverage: - improvements to the RN packager - general RN improvements accumulate over time - developments in packagers (https://github.com/facebook/react-native/issues/13976 and https://github.com/callstack-io/haul) - yarn improving on npm - cljs supporting npm dependencies - maybe webpack could help as well, eventually - learnings from boot-react-native and re-natal - improvements in figwheel, boot-figwheel

carocad11:05:44

@pesterhazy have you tried haul? I have not seen a reason to switch yet and I (personally) don't like so many moving/unstable pieces at a time.

pesterhazy13:05:33

I agree about stability, which is why I haven't tried haul yet.

mfikes13:05:32

Speaking of stability, how often does React Native changes break re-natal-based apps these days? (Have things become relatively stable, compared to the early days where things broke, say, every month or so?)

mfikes13:05:05

(Speaking from my earlier experience with Ambly/`natal`, where things were in a lot of flux.)

pesterhazy13:05:17

Not sure about re-natal, but from what I hear the maintainer is doing a great job of keeping it in sync with RN

pesterhazy13:05:12

I know I've struggled to keep up in boot-react-native, which doesn't work with recent versions of RN

pesterhazy13:05:29

rn is a great project, but stability for external tooling authors is not one of their to priorities

mfikes13:05:40

I have a concern (owing to lack of experience) of working on a project that may span a few years where things might regularly break. In fact, I couldn't figure out how to get natal to work with the latest RN code, as it has evolved with respect to how you inject your own JavaScriptCore context, which the Ambly approach depends on.

mfikes13:05:06

Is using npm shrinkwrap a best practice? (Again, I'm not familiar with this ecosystem and what you must or should do, in order to maintain sanity.)

pesterhazy13:05:33

You mean for npm in general?

mfikes13:05:07

Yep, this is a bigger issue than RN.

pesterhazy13:05:30

Using shrinkwrap, or yarn, is definitely an improvement IMO

mfikes13:05:49

Oh. I've heard of yarn. I'll read up on it.

pesterhazy13:05:55

I'd go with yarn by default these days

pesterhazy13:05:32

It's pretty much a drop in replacement for npm, except deterministic and faster

mfikes13:05:35

I just want to know that, if I'm working on an app, and come back to it a few months later, it will still work. 🙂

mfikes13:05:53

(And only break if I choose to upgrade deps.)

mfikes13:05:37

Thanks @pesterhazy — yes, the non-determinism of npm is, I suppose, what was bothering me.

carocad19:05:11

hey @vikeri I have seen you using the "@flow" statement in your public repos. Does it actually help? I was thinking of using it for a CI script but I am a bit afraid of how it might play together with cljs, any advices 🙂 ? https://github.com/vikeri/re-navigate/blob/master/src/re_navigate/core.cljs#L7

nikki19:05:57

seems it doesn't do the figwheel-bridge.js that re-natal does