Fork me on GitHub

A little quiet over on #figwheel-main: anyone know how to handle these requires with that? I do not even understand the f'ed up npm (?) syntax. Whassat, some kind of wildcard?


You might have better luck using (js/require ….


@hiskennyness but what happens?


it can most definitely work


I haven't found anything in RN that can't required properly in the past year


Well, @dnolen, it works great in shadow, but fig:main actually touts that it does not do

["react-native" :as rn]
["react-native-elements" :as rne]
Instead this does work:
[react-native :as rn]
[react-native-elements :as rne]
With this in the NS: ["@react-navigation/native" :refer [NavigationContainer]] I get:
WARNING: Use of -A with clojure.main is deprecated, use -M instead
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See  for further details.
[Figwheel] Compiling build ios to "target/public/cljs-out/ios-main.js"
[Figwheel] Failed to compile build ios in 5.581 seconds.
[Figwheel:WARNING] Compile Exception   src/mxrn/demo/navi.cljs   line:14  column:7

  No such namespace: @react-navigation/native, could not locate _CIRCA_react_navigation_SLASH_native.cljs, _CIRCA_react_navigation_SLASH_native.cljc, or JavaScript source providing "@react-navigation/native" (Please check that namespaces with dashes use underscores in the ClojureScript file name) in file src/mxrn/demo/navi.cljs
I did try various permutations without strings, but then it hated the "/" divider. Lemme see if I can find the fig:main reference to NS requires...


@hiskennyness what version of Figwheel


the error is telling you that it cannot find that library in node_modules so that's a hint


maybe wrong version of Figwheel, maybe wrong version of ClojureScript


I went with the startup tutorial

{:deps {org.clojure/clojurescript {:mvn/version "1.10.773"}
        com.bhauman/figwheel-main {:mvn/version "0.2.14"}}
 :paths ["src" "target"]}


Hmm, I see a readline dependency documented elsewhere. Lemme try that... 🀞


Nope. Same error.


I see a 0.2.6 version in a sample gist: More 🀞 ....


Well, I get an early error now off the prescribed ios.cljs.edn, which is:

^{:react-native :expo} ;; use :expo if you are using Expo
{:main mxrn.main}
Under figmain 0.2.6 I now get:
DEPRECATED: Libs must be qualified, change cljs-http => cljs-http/cljs-http (deps.edn)
WARNING: Use of -A with clojure.main is deprecated, use -M instead
2021-09-01 09:48:08.024:INFO::main: Logging initialized @9234ms to org.eclipse.jetty.util.log.StdErrLog
Configuration error in build options meta data: ios.cljs.edn
-- Unknown map key ----------------

  {:react-native ...}

should be one of

  :ring-stack, :client-log-level, :post-build-hooks, :validate-config, :ring-handler, :bundle-once, :repl-eval-timeout, :pprint-config, :log-level etc etc etc
Encouraging, in a way only a developer would understand. πŸ™‚


Commenting out the ^{:react-native :expo} yields

WARNING: Use of -A with clojure.main is deprecated, use -M instead
2021-09-01 09:56:50.417:INFO::main: Logging initialized @9640ms to org.eclipse.jetty.util.log.StdErrLog
[Figwheel] Compiling build ios to "target/public/cljs-out/ios-main.js"
  throw err;

Error: Cannot find module '@cljs-oss/module-deps'
Require stack:
β€’ /Users/kennethtilton/dev/matrix/cljs/mxrn/[eval]
etc etc
🀷 Things do seem to be afoot. Lessee what @bhauman knows. 🀞


@hiskennyness pretty sure you need to bump ClojureScript one second


yes you do


but might as well go to the lastest


Now that looks promising! Thx! πŸ™ brb....


Well, neither 1.10.844 nor the latest 1.10.879 could handle the string version (same ^^^ error), so I tried suggested non-string variations, including their own example

[react-native$NativeModules.SomeUnlikelyBridge :as woz]
...and that compiles (despite the name, but 🀷). Sadly, nothing I tried with real requires from react-navigation$.... worked (threw same error I started with) but the one working version gives me hope. I will keep plugging. Thx for the input, @dnolen! Those release notes alone are a great help, and I will stick with the latest CLJS>


@hiskennyness is @react-navigation in your node_modules ?


the error says it cannot be found, so double check that


Yep, I was just going to reinstall. Thx!


and even after that look in there


given it's a RN module - you also definitely need a pod install if this iOS


after the npm install


Yep and yep. I was thrashing and zapped my node_modules more than once. I am back to the strings, btw. Yer a genius! Thx. πŸ™ I do not see a cljs dependency in my shadow-cljs version of the same project, where the strings worked. Guessing it automatically picks up the latest, which is why I never had a problem there. It's a good thing I like programming. πŸ™‚ Thx again.


FWIW shadow-cljs just lets metro resolve the strings and doesn't attempt to do anything itself, so it never looks at node_modules in case of :react-native builds (as long as you use strings, symbols it has to look)


but note that is just non-standard behavior, you cannot rely on this everywhere


if you stick to the ClojureScript semantics it is compatible and you can switch between tools when you need to


Interesting, @thheller. I will prolly bounce back to shadow before I am done, but every example out there uses re-frame or reagent. I think maybe one fulcro example was the exception. I will also look just wiring shadow into an existing project from the instructions on doing that manually. I just like to save a lot of time working from working code. Time to roll up the sleeves, I guess.


i.e. use strings if you like since it's always equiv to symbols - only shadow-cljs treats them as special


string support only exists in ClojureScript because JS libraries can have non-valid symbol chars in the name


shadow-cljs also supports thing you should be very careful to avoid in the ns form


if you want the freedom to use what tool you want


based on reports elsewhere there's a lot of confusion about what is shadow specific, even w/ the existing docs


The one thing I liked about shadow-cljs was a more powerful features mechanism than can be had with #?. But we think we found a not too ugly way of providing different MQTT libraries to Web JS and RN.


shadow-cljs does something here which is also not recommended


because no standard Clojure thing support extended reader conditionals


well since CLJS supports strings code will just works in regular CLJS as well. nothing shadow-cljs specific here. just the recommendation is to use strings for JS stuff to make them explicit as a JS deps


entirely my subjective recommendation. not required at all.


I don't like the idea of my requires working depending on whether a node_modules folder exist or not


I'm not talking about opinions about any the above matters


I did find it interesting that I had to "port" my app from shadow to figwheel:main, but I am deeply impressed that these tools do what they do, so I just keep on typing. πŸ™‚


curious about what you actually needed to "port"? apart from configuration it shouldn't require many code changes?


It's complicated. And it is not just shadow->figwheel:main. First of all, I forgot the one Reagent-free lib I did find and worked from! Helix, including two Helix Native libraries @U0Q12NFPU put together. So my init function starting from Helix is

(defn init []
  (let [app-matrix (build/matrix-build!)
        root (mget app-matrix :rx-dom)
        rendering (fnc [] (mget root :rendering))]
    (rn/AppRegistry.registerComponent "MyApp"
       (fn [] rendering))
Looks like standard RN code. But when I got to figwheel:main native I found
;; the function figwheel-rn-root MUST be provided. It will be called by
;; by the react-native-figwheel-bridge to render your application.
(defn figwheel-rn-root []
  (let [app-matrix (matrix-build!)
        root (mget app-matrix :rx-dom)
        root-element #_(renderfn {}) (mget root :rendering)]
Mind you, the asininity of ReactNative deserves a lot of credit. I am grateful for native solutions that help me just ficus on RN, but they do create incompatibilities. Then sample figmain code had symbol requires, and somewhere some discussion of that as a feature, so that is where I started thinking, "so much for portability!" When I got to strings like "@react-navigation/native" and had no idea how to convert to symbols...but Mr. Nolen got me sorted out with a fresh CLJS version, so scratch that. Thx again for shadow! My boss is pissed I am looking at figwheel, he loves shadow, I may be back. πŸ™‚


Oh, another thing, and again this is about HelixRN: that has the npx-generated react native folder inside the project folder. With fig:main I add fig elements to the npx-genned folder.


hmm interesting. I guess there are some slight differences


the extra folder isn't strictly necessary for shadow-cljs either. just a personal preference of mine to keep this RN stuff out of my "sane" CLJS world πŸ˜›


or anything generated really. makes it easier to switch RN versions later and so on

πŸ‘ 2

just how ClojureScript actually works and if you want stuff to portable between the tool set


@hiskennyness btw, cool to see you digging into Clojure(Script)


I ran across your Common Lisp posts a lot when I was getting into Lisp in earnest back in 2007 πŸ™‚


God I miss comp.lang.lisp. 😭


Haha, 2007 was about when I got into Clojure based on a recommendation from someone I respected, and the job market for Clojure did not hurt.