Anyone here have experience using figwheel-main and react-native-figwheel-bridge with …Android?

@bobby.harris Is this any help with the issue you were having with react-native-figwheel-bridge https://github.com/bhauman/react-native-figwheel-bridge/issues/2

@codonovan That definitely addressed the issue I was seeing, which for posterity was an incredibly context-free [goog.net.WebSocket] An error occurred: undefined red-screen

The chrome debugger was a little more helpful in this instance.

[goog.net.WebSocket] An error occurred: undefined
[goog.net.WebSocket] The WebSocket on  closed.
[goog.net.WebSocket] The WebSocket disconnected unexpectedly: undefined

heads up I just made a significant revision to https://github.com/bhauman/react-native-figwheel-bridge

@chris_johnson please help by adding this information to the README

well that sounds a little to pleading

are there any other things you have noticed for android?

I haven’t gotten around to booting it up

and I meant to address that to @codonovan 🙂

Not yet. I am working on a full soup-to-nuts example of using Figwheel.main, the RN bridge, and the Clojure CLI to build a React Native app so I will be exercising Android quite a bit.

I'm playing with the new version now and getting some errors, which I'm working through

awsome!!

make sure you have the latest 0.2.1-SNAPSHOT

I hope to publish it soon, and go back and refactor it into the sample repo from my conj talk

Okay, I will update now and see what, if anything, breaks. 😇

oh stuff will break

the options are different

make sure you are using figwheel-main

The key difference is that figwheel main is outputing a cljsc_opts.json file that you can point the figwheel-bridge to

since this file has all the config info in it, the configuration is much harder to mess up

oohh the readme is rough going over it again now

@chris_johnson first thing that will break is Android needs another reverse proxy.

adb reverse tcp:9500 tcp:9500;adb reverse tcp:8081 tcp:8081

thanks for the heads up

oh really?

Yeah, we always have to this stuff on android. Even with vanilla RN and re-natal

I don’t understand by that would be the case?

oh OK

I’m wondering if it makes sense to write a custom myproject.main that wraps figwheel.main and does all the RN bookkeeping (possibly also e.g. running a prophylactic watchman watch-del-all on every restart :D)

I can't explain why, sorry. Just always been the case https://facebook.github.io/react-native/docs/running-on-device#method-1-using-adb-reverse-recommended

I might end up doing that anyhow to create a launch environment that supports CIDER/nREPL in a “press button, receive REPL” fashion

@chris_johnson a makefile or script would serve that purpose better 🙂

That’s certainly true

or just a Clojure script

build.clj

My current (boot/Expo) version of a RN project definitely has a hefty Makefile but we’re doing all kinds of uh, interesting stuff like supporting multiple build flavors of the app

I would keep tooling light as both I and David Nolan are looking very closely at React Native integration

the Makefile is great for low commitment, and getting things working

that’s exciting news

yeah, I will surely end up with a Makefile for handling some of the build process eventually, I guess I was really thinking this process through in one direction (desire for CIDER integration to leverage my muscle memory -> custom main that sets up CIDER + Figwheel.main -> if I have a custom main why not put this other mechanical work in there) but I am thoroughly convinced by just explaining that out loud that it’s borrowing trouble to do things that way

I’m also not 100% convinced that I will need CIDER once I actually have a project example that uses Figwheel properly in a react native project, which I have not yet had, so we’ll see how that goes

@chris_johnson I did some work on a React Native project and the started an nREPL server manually and used cider-connect-cljs instead of cider-jackin

it was definitely more flexible

hm, so starting the nREPL server inside the running Figwheel REPL instead of the other way around?

I definitely prefer to run the nREPL server outside and cider-connect for JVM projects

I would say having CIDER integration is pretty killer especially for React Native

for instance having a build.clj script that starts nREPL and figwheel.main

so I would be doing that here as well, but all the documentation I’ve encountered so far is about running an nREPL server and then kicking off Figwheel inside that, if it works to do it the other direction I’m all for it

yep it works

IMHO cider-jack-in is a really cool thing that is actually not great to actually use

what I like a bout cider jack in is that I can move between projects and just get a repl really quickly

like, do it once, say “I’m in” in your Extremely Hacker Voice, then take off your indoor sunglasses and run your REPL process outside your editor like a boring salaryman

I prefer cider-jack-in unless a project punishes me for it, which cljs can do sometimes when it hangs

anyway let me know if you come across strangeness with the new bridge

Another thing to note is that the build is no longer :target :nodejs

I'm getting

[Figwheel:WARNING] Attempting to dynamically add "target" to classpath!
[Figwheel:WARNING] Target directory "target" is not on the classpath
[Figwheel:WARNING] Please fix this by adding "target" to your classpath
 I.E.
 For Clojure CLI Tools in your deps.edn file:
    ensure "target" is in your :paths key

 For Leiningen in your project.clj:
   add it to the :resource-paths key

[Figwheel] Compiling build android to "target/public/cljs-out/android-main.js"
[Figwheel] Failed to compile build android in 0.376 seconds.
[Figwheel:WARNING] Compile Exception   src/awesome/main.cljs   line:2  column:14

  No such namespace: react, could not locate react.cljs, react.cljc, or JavaScript source providing "react" in file src/awesome/main.cljs

  1  (ns awesome.main
  2    (:require [react]
                  ^---
  3              [react-native :as rn]))
  4  
  5  (def <> react/createElement)
  6  
  7  (defn renderfn [props]

[Figwheel:SEVERE] clojure.lang.ExceptionInfo: No such namespace: react, could not locate react.cljs, react.cljc, or JavaScript source providing "react" in file src/awesome/main.cljs

I've added src and target to :paths but still getting No such namespace: react, could not locate react.cljs, react.cljc, or JavaScript source providing "react" in file src/awesome/main.cljs

so did you alter your index.js file and setup the dummy.js file?

@codonovan ^

Yes I believe so, just running the readme again

oh and you should probably clean the target

I was seeing that when I updated my Clojurescript dep to a newer version than 1.10.339

yeah npm-deps defaults to false in 1.10.439

possibly unrelated of course, but it appeared that making that change broke my build in exactly that way, and reverting the dependency fixed it

no you got it right

the removal of :target :nodejs is a big change but its the smartest thing to do in this circumstance

AFAIK

you have to name cljsExports exactly cljsExports

@bhauman I can't seem to find cljsc_opts.json anywhere under /target

you may have to remove figwheel-main and friends from your .m2 repository

and reinstall them

oops I'm getting ahead of myself still the error posted above. OK, will do

darn I have to go to an eye exam. I’ll be back later.

I hope your exam is uneventful and they have cool frames for you if you are getting ’em.

well I just followed the setup instructions and it failed, so something is wrong

OK it has to be the latest version of CLJS

just updated the README

Awesome, I was confused about what was going wrong.

Hi! Anyone used react-native-qrcode-scanner?