Fork me on GitHub
#cljsrn
<
2021-09-01
>
kennytilton11:09:52

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? https://clojurians.slack.com/archives/CALJ3BFLP/p1630484717008700

pez11:09:55

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

dnolen13:09:14

@hiskennyness but what happens?

dnolen13:09:27

it can most definitely work

dnolen13:09:51

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

kennytilton13:09:10

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]
[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...

dnolen13:09:12

@hiskennyness what version of Figwheel

dnolen13:09:28

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

dnolen13:09:39

maybe wrong version of Figwheel, maybe wrong version of ClojureScript

kennytilton13:09:20

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"]}

kennytilton13:09:10

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

kennytilton13:09:51

Nope. Same error.

kennytilton13:09:52

I see a 0.2.6 version in a sample gist: https://gist.github.com/bhauman/a5251390d1b8db09f43c385fb505727d More 🀞 ....

kennytilton13:09:47

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. πŸ™‚

kennytilton14:09:55

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"
node:internal/modules/cjs/loader:927
  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. 🀞

dnolen14:09:19

@hiskennyness pretty sure you need to bump ClojureScript one second

dnolen14:09:46

yes you do

dnolen14:09:57

but might as well go to the lastest

kennytilton14:09:49

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

kennytilton15:09:12

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>

dnolen15:09:47

@hiskennyness is @react-navigation in your node_modules ?

dnolen15:09:03

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

kennytilton15:09:31

Yep, I was just going to reinstall. Thx!

dnolen15:09:44

and even after that look in there

dnolen15:09:20

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

dnolen15:09:27

after the npm install

kennytilton15:09:54

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.

thheller15:09:48

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)

dnolen15:09:57

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

dnolen15:09:17

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

kennytilton15:09:46

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.

dnolen15:09:02

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

dnolen15:09:05

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

dnolen15:09:24

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

dnolen15:09:33

if you want the freedom to use what tool you want

dnolen15:09:46

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

kennytilton15:09:31

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.

dnolen15:09:49

shadow-cljs does something here which is also not recommended

dnolen15:09:09

because no standard Clojure thing support extended reader conditionals

thheller15:09:12

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

thheller15:09:30

entirely my subjective recommendation. not required at all.

thheller15:09:55

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

dnolen15:09:13

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

kennytilton15:09:28

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. πŸ™‚

thheller15:09:57

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

kennytilton16:09:32

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))
    (refresh/inject-hook!)))
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)]
    root-element))
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. πŸ™‚

kennytilton16:09:25

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.

thheller17:09:14

hmm interesting. I guess there are some slight differences

thheller17:09:09

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 πŸ˜›

thheller17:09:35

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

πŸ‘ 2
dnolen15:09:31

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

dnolen15:09:22

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

dnolen15:09:43

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

kennytilton15:09:46

God I miss comp.lang.lisp. 😭

kennytilton15:09:32

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.