This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws-lambda (1)
- # beginners (99)
- # boot (46)
- # cider (8)
- # cljs-dev (20)
- # cljsrn (37)
- # clojure (189)
- # clojure-dev (22)
- # clojure-dusseldorf (28)
- # clojure-italy (1)
- # clojure-russia (28)
- # clojure-spec (10)
- # clojure-uk (33)
- # clojurebridge (1)
- # clojurescript (64)
- # core-matrix (2)
- # css (3)
- # cursive (3)
- # datascript (34)
- # datomic (101)
- # defnpodcast (2)
- # dirac (5)
- # events (1)
- # funcool (3)
- # ldnclj (1)
- # lumo (11)
- # mount (1)
- # off-topic (95)
- # pedestal (2)
- # perun (10)
- # re-frame (3)
- # reagent (6)
- # ring-swagger (4)
- # specter (102)
- # test-check (1)
- # untangled (1)
- # vim (8)
- # yada (17)
@vikeri I have to change Product Scheme's Build Configuration to Release to make it work. Just curious, do we have to do the this thing for every other react project ( I had the same error all the time with react native project ). The error is:
yeah. I got the error then I have to edit Product Scheme and run the project within xcode to make it work.
I'm not sure what's wrong but I have this kind of problem all the time when I try out react native project.
I know this has been discussed several times, but which http library are people using? We’ve been using raw js/fetch but now is the time for something proper. I know cljs-http doesn’t work with js/fetch out of the box. What about cljs-ajax?
> It's early days but I feel ClojureScript + Expo is one of the best options for building large, sophisticated apps on mobile. I'm sceptical. Expo has its limitations and if you're able to stay within them, it's great.
However, the moment you need to introduce any native code (that is not not part of Expo) by yourself, you lose all the benefits
Exactly, for CRUD-apps, awesome! For apps that need Bluetooth, Background jobs etc. Impossible.
IMO, if you're the both PO and dev on the project, for example working on something small and not complicated - sure, you can benefit from it But if you're working on a bigger project and have outside requirements - I wouldn't bother with Expo
Would it be very difficult to write an Android/iOS wrapper to hook into the Expo framework?
I'm not sure that's possible (definitely not easy) - Expo is not a framework, but a whole application platform
well if you added another component to their platform you could encapsulate the native code I would think
@dehli I assume that a lot of the benefits will break as soon as you put your native code into the mix. You can’t just load whichever js bundle then and make them run anymore for example. The point of Expo is that all apps have the exact same Native code, which means that a lot of assumptions can be made.
Gotcha, ya that makes sense. What are some examples of things that cannot be done in Expo?
I'm not really up-to-date with what's currently built into Expo, but two things come to my mind straight away: * background jobs: you can't do them in JS, need to write native code * integrating with less popular SDKs: if Expo doesn't contain a wrapper for them already, you're in trouble
@wojciech Actually, we’re doing background jobs in js: https://github.com/vikeri/react-native-background-job but it relies on Native code.
> This library relies on React Native's HeadlessJS which is currently only supported on Android. Do I understand properly it won't work in iOS?
Yes, HeadlessJS is not implemented there yet. And actually the background job story for iOS is a lot more restricted
gotcha, so client heavy apps are gonna be tough using expo but they’d be pretty tough with react native as well i’m guessing
It's all relative. React native in general allows you to simplify the amount of duplicate code you have to write and maintain. The trade-off is upfront work in research and evaluation. Clojure can simplify your codebase further but the language is arguably harder to hire for