@joshmiller thanks for linking that example. i tried importing the map view component the same way, but i still seem to get that error here is the full stack trace: https://pastebin.com/raw/AKWfYiZR this is the file where i'm using the map view: https://pastebin.com/4hTwQiSp

@dilin Hm, weird. If you replace the map-view with just [text "hello"] does it fix it?

And how is map-view defined in your bus.common.ui ns?

yes it does appear to fix the app if i replace the map-view

this is how i'm importing it:

(ns bus.common.ui
  (:require [reagent.core :as r]))

(def ReactNative (js/require "react-native"))

(def app-registry (.-AppRegistry ReactNative))

(def text (r/adapt-react-class (.-Text ReactNative)))
(def view (r/adapt-react-class (.-View ReactNative)))
(def image (r/adapt-react-class (.-Image ReactNative)))

(def map-view (r/adapt-react-class (js/require "react-native-maps")))

i made sure that the library was picked up by figwheel and installed correctly as well

@dilin Ahhhhh, there’s your problem

It should be (def map-view (r/adapt-react-class (.-default (js/require "react-native-maps"))))

Note the default there.

pro tip: after adding a new npm lib, in the figwheel repl, type (js/require "my-library")

you'll see if you (a) forgot to restart the repl or add the line to .re-natal and (b) if the library requires .-default

@pesterhazy I am also using react-native-maps and I never had to do that. I do [:> expo/MapView props ...] and for importing it is simply (def MapView (.-MapView Expo))

I didnt know that this default thing was needed 😄

Some NPM libraries require it (those using ES6 modules)

Anyone have pointers / experience with putting together "CI" unit tests for Cljs + RN apps, i.e., ones that can run from the command line. I'm assuming that it is possible to write tests that focus on the pure, or close to pure functions in your app, but even in that limited scenario, I don't have experience getting it to run in a "headless" environment and curious what people tend to do for this. I also quickly tried to use the react-native test render, but was unable to get that thing to work.

(In the past, I have run my unit tests directly from the REPL using cljs.test/run-tests, but want to have this done in CI, essentially.)

Do you want to test the RN part as well, or only the ClojureScript parts?

What I mean is, do you want to run the actual app with its ObjC shell etc.?

From what I understand, an iOS app built for the simulator is just an macOS binary, so it might be possible to run it outside the simulator, but not sure how far you'd get

Minimally, I want to be able to write ClojureScript-based tests that don't involve the actual app. That would be an improvement over what I'm currently doing. But if there are more aggressive ways to include more of the app / RN runtime in CI, that would be cool tool.

I'm mostly curious if this is a road that devs have gone down and solved in some way.

Frankly I've shied away from it where I can, because of the inevitable incidental complexity surrounding iOS tooling

I think I'm OK with writing tests against pure functions that produce view Hiccup. But, I'm also curious if people end up having buttons being pressed in an automated fashion, etc.

There's no reason you shouldn't be able to run the CLJS bundle built from lein in chrome-headless, or from node

Yeah, that's where I'm at. My only approach right now is to put a lot of code that doesn't depend on RN into a "library" or subtree of my code so that I can just run it using Doo in, say Node, for example.

So for pure functions that should give you an approximation

The benefit being that you don't have to deal with XCode silliness

There's also the equivalent of Selenium tests for iOS apps

I went through https://github.com/Day8/re-frame/wiki/Testing and came away with the feeling that just testing the pure functions is what people probably tend to do.

I used a standard framework before that uses accessibility labels to identify buttons etc, and it works with CLJSRN

Ahh, right, I've used something like that, using Automation or somesuch from OS X at the time.

Can't remember the name now... It was brittle, as you can expect, and you had to write the tests in ObjC

It was more integrated than that...

Yep, I only did that once to repeatedly press a certain button sequence over and over to try to find leaks or crashes.

Ah it was KIF

These days there's Appium which I haven't tried but maybe it's better

So, I'm mostly curious about the Chrome Headless or Node mode. I'm assuming that the trick is to build a ClojureScript bundle (perhaps :whitespace or :simple?) that also includes the test runner, and then to kick that off.

Well you're building a CLJS bundle anyway for your production builds, right?

Yeah, right. No harm in testing with :advanced

The re-natal template should be set up to do that

Yep.

I've never had a CI script run this on a remote server. I'm assuming the packager gets launched as a separate process, etc. I'll find out.

So the bundle could be built in such a way that the init function isn't called when run from node, or similar

yes, it's part of the XCode project (the final step)

I think I can get a good amount of mileage out of this approach. Thanks Paulus 🙂

https://github.com/facebook/react-native/blob/master/scripts/react-native-xcode.sh

np 🙂

One thing to watch out for is the (def view (r/adapt-react-class (.-View react-native))) pattern

this will blow up if react-native isn't actually present

and unfortunately this is executed on namespace init time

Ahh. Interesting. Perhaps that can be solved with some clever code arrangement.

a hack like this might help

(defn safe-adapt-react-class [klass]
  (if klass
    (r/adapt-react-class klass)
    (constantly nil)))

Cool

The other thing I really recommend is to set up CI to build TestFlight pre-releases for every push to git

This makes manual testing on an actual device a breeze

It's a bit of upfront work but pays off in no time

Ahh, that would indeed be nice. I suppose all of that can be automated from the command line as well.

Yes it can. fastlane is the tool to use here, and works well with cljsrn

Cool. TIL

You must have more iOS experience than me, but if I can help out, let me know

Thanks, I'll drop more questions in here if I encounter any. My iOS dev experience goes back to around 2012 (iOS 5?), but it has always been outside of corporate settings (always for myself).

I'm curious if the "run bundle in node" approach works out for you

@pesterhazy Yeah, I'll ping you with an experience report after. 🙂

I would also be interested to know how that works out for you. Currently, we’re doing essentially all of our CI testing as Appium/Python (our test engineer likes using Python for this and since he produces tests faster than our whole team can write features to cover, that’s A-OK with me 🙂 ) and we build with Fastlane/CircleCI

Our test coverage comes from two main sources: 1) TestFlight and APK builds are created for every push and 2) we run a “nightly” build in CircleCI that uploads those artifacts and the test package to AWS Device Farm and runs all our integration tests on ~15 devices across the spectrum of iOS and Android things we think might reasonably be used by our customers

@joshmiller thanks a lot! that fixed it