This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-05-04
Channels
- # announcements (1)
- # asami (61)
- # babashka (71)
- # beginners (170)
- # biff (1)
- # calva (14)
- # clj-kondo (23)
- # cljsrn (28)
- # clojars (1)
- # clojure (152)
- # clojure-australia (2)
- # clojure-europe (65)
- # clojure-nl (2)
- # clojure-spec (8)
- # clojure-sweden (3)
- # clojure-uk (45)
- # clojurescript (1)
- # css (12)
- # cursive (16)
- # datomic (9)
- # devcards (2)
- # emacs (1)
- # events (1)
- # graalvm (31)
- # honeysql (10)
- # jackdaw (2)
- # jobs (5)
- # lambdaisland (9)
- # lsp (4)
- # malli (11)
- # meander (43)
- # off-topic (6)
- # pathom (7)
- # polylith (1)
- # portal (14)
- # re-frame (7)
- # releases (1)
- # remote-jobs (1)
- # rewrite-clj (6)
- # shadow-cljs (101)
- # specter (1)
- # tools-deps (26)
- # vim (9)
- # xtdb (2)
@dsp also, I notice you’re using some lein template of “expo”; You should make sure that’s up-to-date or not use it. In general, I would recommend using the standard React Native tooling as much as you can, including to initialize the project structure, etc. That will ensure you’re using most recent versions. Things have somewhat stabilized in the RN ecosystem but still critical IMO to stay on the latest versions. This is very unlike server-side Clojure, where it barely matters if you’re on 1.8, 1.9, 1.10, etc but unfortunately “it is what it is”.
I’ve followed instructions here most recently, and they should work for getting a dev setup running with figwheel-main: https://figwheel.org/docs/react-native.html
@dsp from what I've gleaned lurking here recent shadow-cljs, figwheel should all be fine for React dev - I agree with @raspasov points - use latest React, avoid templating-heavy stuff. Krell was useful but flaky for the past year - but we haven't had any problems w/ it with the latest fixes and we're using it on two non-trivial apps at work.
yep, managed to get everything working well enough. now i just need to figure out how react native works, and the workarounds needed for clj.
i suspect using things from the js ecosystem requires actually knowing how those things work, and thus there's no way around learning the js side of stuff for using it in cljs
still, the idea of running more-or-less plain clojure on mobile devices is appealing enough to probably be worth the pain
I think ClojureScript to build mobile apps is in fact a killer app for ClojureScript

Not only that, recently I've had to start writing RN apps for a website I've made in clojure/script that's been running for about a year. Being able to completely share all my re-frame events/subscriptions that fetch APIs and manage state is saving me an enormous amount effort. It's become extremely apparent how well re-frame's recommendation to keep events as pure functions is helping me deal with all this too and making this possible.

we even build "native" SDKs in ClojureScript for Java/ObjC/Swift and these are dev'ed w/ Ambly
I would not use plain RN and the standard mobile platform dev tools are light years behind wrt. collapsing the cycle
I haven't tried Dart yet for mobile dev, perhaps the dev loop there is better than RN now?
There is currently a ClojureDart project under way: https://twitter.com/BaptisteDupuch/status/1388449877747720192
That would presumably let you build a Flutter app in Clojure
I prefer RN’s model of driving actual native components with JS to the Flutter canvas-type model though
I fiddled with flutter some, it is fast enough and does hot reloading, well enough to be a fairly productive platform (I only tinkered for about 4 work days though.) plus, you can release the same app to all of the 5 major platforms; linux, chrome, ios, android, web
@bherrmann my feeling is the hot-reloading is more sophisticated / useful since it's fundamental to the VM - i.e. instance state is preserved
@bherrmann I'm assuming no REPL to the running app though?
In particular things like manipulating JSON (in my experience) come in two flavors; 1) a handy way to map the JSON to a tree of dart code (static mapping) 2) a bag of values that you to sift through on your own... So I felt like there was no convenient blend of working with information that we take for granted in clojure land... (These memories are from probably 3 months ago)
On the plus side, you could tell Flutter has an absolute ton of people at google working polishing the heck out of it. A lot of things were well done and very high polish.
Yeah I'm also interested in knowing more about this, mainly what kinds of problems this allows you to solve that a normal cljs + RN environment doesn't. Also ambly says it's for iOS, is there a dev version that works with java/android?
Not only that, recently I've had to start writing RN apps for a website I've made in clojure/script that's been running for about a year. Being able to completely share all my re-frame events/subscriptions that fetch APIs and manage state is saving me an enormous amount effort. It's become extremely apparent how well re-frame's recommendation to keep events as pure functions is helping me deal with all this too and making this possible.
