This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-05-28
Channels
- # beginners (67)
- # boot (31)
- # cider (1)
- # cljs-dev (12)
- # cljsjs (1)
- # cljsrn (23)
- # clojure (86)
- # clojure-russia (2)
- # clojure-spec (6)
- # clojure-uk (12)
- # clojurescript (171)
- # core-async (2)
- # core-matrix (1)
- # cursive (3)
- # events (1)
- # lumo (6)
- # off-topic (118)
- # om (51)
- # onyx (16)
- # perun (3)
- # re-frame (14)
- # reagent (19)
- # uncomplicate (5)
- # unrepl (6)
- # untangled (6)
@carocad looks promising
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
@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.
I agree about stability, which is why I haven't tried haul yet.
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?)
(Speaking from my earlier experience with Ambly/`natal`, where things were in a lot of flux.)
Not sure about re-natal, but from what I hear the maintainer is doing a great job of keeping it in sync with RN
I know I've struggled to keep up in boot-react-native, which doesn't work with recent versions of RN
rn is a great project, but stability for external tooling authors is not one of their to priorities
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.
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.)
You mean for npm in general?
Using shrinkwrap, or yarn, is definitely an improvement IMO
I'd go with yarn by default these days
It's pretty much a drop in replacement for npm, except deterministic and faster
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. 🙂
Thanks @pesterhazy — yes, the non-determinism of npm
is, I suppose, what was bothering me.
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
has anyone used https://github.com/artemyarulin/ktoa much?