This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-21
Channels
- # admin-announcements (3)
- # beginners (15)
- # boot (96)
- # cider (5)
- # cljsjs (2)
- # cljsrn (3)
- # clojure (22)
- # clojure-austin (2)
- # clojure-russia (16)
- # clojured (2)
- # clojurescript (65)
- # css (4)
- # cursive (89)
- # datomic (7)
- # emacs (89)
- # events (1)
- # hoplon (126)
- # leiningen (2)
- # off-topic (2)
- # om (268)
- # onyx (19)
- # parinfer (42)
- # re-frame (5)
- # reagent (30)
- # yada (8)
hey all, I’m really interested in a high-level overview of some of the main issues / points of contention at the interface between react native and cljs tooling. I understand that @mneise did some awesome initial work to make it possible to ingest different js module formats, but as far as I can tell react native continues to use its own bespoke packager tool: https://github.com/facebook/react-native/tree/master/packager with odd primitives like @providesModule. Can somebody help fill in the gaps, re: how this impacts cljs tooling and maybe insight into how we can improve the situation?
reading through http://cljsrn.org/roadmap.html and trying to grapple with this
in some senses it sounds like maybe the best way I can contribute is help with the react native codebase itself towards emitting proper commonjs modules as suggested over a year ago? https://github.com/facebook/react-native/issues/5