@thheller Hi. I submitted a PR for reagent-expo yesterday to upgrade it to work with Expo SDK 44 and EAS Build. I also added a way to block Expo Web’s fast refresh and removed that section from the README. If you have a chance to check it, please let me know if I need to change anything 🙂 https://github.com/thheller/reagent-expo/pull/10

what is a EAS build?

It’s Expo’s new way of building which allows you to incorporate custom native code. The old way of building is currently still supported, but will be going away at some point. EAS Build allows you to continue using the Expo Managed workflow, and still install dependencies that you would previously have had to eject for. You can also build plain React Native apps using EAS Build.

EAS == Expo Application Services

https://docs.expo.dev/eas/

ah ok

I don't follow Expo at all so I don't have any way of checking your PR. I'm fine with merging it if you accept that I direct people asking questions your way 😉

hehe 🙂 you can point them at http://forums.expo.dev and there’s a good chance I will see there question and answer them there.

I understand if you don’t want to bother, but it’s really easy to try it out: • Create an Expo account (I think you might have done this in the past) • npm i -g expo-cli eas-cli # there’s a weird yarn bug that sometimes happens when installing these globally with yarn • clone the reagent-expo repo • run yarn to install the dependencies The development instructions are unchanged. The instructions for building a standalone app that you can submit to the App/Play stores is now just basically “run eas build ...” because npx shadow-cljs release app is run as part of the build. So for example you can run: eas build --platform=android --profile=preview which will build a .apk that you can install on an Android device. The first time you do this it will ask for the Android package (which is normally something like io.github.shadowcljs.reagentexpo (Android doesn’t like dashes there for some reason)). If you build for iOS then it will ask for a bundleIdentifier which is basically the same thing for iOS (but dashes are allowed there.) It will also generate a default eas.json config file.

yeah sorry I'm not gonna do any of that. way too swamped already and no time to look into what looks like an entire new ecosystem

No problem

as far as I can tell from your PR nothing on the shadow-cljs changed at all

I can't possibly keep up with all the platform changes happening elsewhere

I understand. Yes, I did not change anything about shadow-cljs (except upgrading the version). The changes were just Expo-related and documentation. I think my PR is useful for people following the link from the Expo section of the Shadow CLJS docs. I’ve pretended that the “classic” build system doesn’t exist for two reasons: 1. The original reagent-expo README basically said :man-shrugging: 2. The classic build system will be going away at some point I will attempt to answer questions people have if you direct them to the Expo forums Thanks for your time and for Shadow CLJS 🙂

Is it possible to control the :asset-path dynamically? Via e.g. setting a top-level JS var on window ? I'm dealing with a convoluted setup that must have the asset path being an absolute URL, even in development, e.g. doing :asset-path "", which works fine, but then I'd like to also test on my phone which means that localhost won't do.

not really no

did you maybe try using the proxy support? https://shadow-cljs.github.io/docs/UsersGuide.html#dev-http-proxy

so that you can use one url but that one talks to other servers?

What about calling manually shadow.loader.init ? It seems to be working in my setup. My generated HTML file is doing roughly

<script src={base-module}>
<script src={main-module}>
<script>shadow.loader.init("")</script>

(with :module-loader-init set to false)

It seems to be working but ideally I should probably put shadow.loader.init after the base module? As, at the time main-module gets loaded, React begins to render so it may trigger asynchronous loading...

well yes that affects the loader but that is not the only use of asset-path

at least not during development

init must be called before and use of the loader

so best in a init method as described here https://code.thheller.com/blog/shadow-cljs/2019/08/25/hot-reload-in-clojurescript.html

The issue with the init method is that it doesn't accept any arguments, so I have to append an extra script tag in my index.html to do this kind of dynamic thing.

well it is not supposed to accept arguments

but you can look at your environment just fine

I could bypass the init-fn entirely and just call my init-fn after I setup the shadow.loader

so for example you can include a <meta name="my-base-path" value="whatever"> in your html

then in init (js/document.querySelector "meta[my-base-path]") to get it out

or <script>_BASE_PATH = "whatever"</script> before the other script takes

and just js/MY_BASE_PATH in the init fn

Right, I can figure that out in multiple ways - I was wondering about that you said about asset-path being used in other places too though?

source maps mostly. if you don't get any warnings/errors regarding those it most likely is fine

Ah right, that's a production concern. In production I hardcode an absolute path for the asset-path. It's only in dev mode that I need to have it dynamic.

dunno what you are doing so can't comment much. normally proxies make all uses of weird server setups unnecessary

(your server may also opt to do the proxying)

also the files generates by shadow-cljs are just static files

so any webserver can serve them. no need to have any built-in shadow-cljs server serve them

What about double proxies? 🙂

But yes, we have a weird setup. Not using shadow-cljs server to serve anything.

It's the module loader that is out of my control, otherwise loading the base files works just fine.

(But it turns out I can init the module loader just fine, so I'm happy. Problem solved 🙂

Hi @thheller, I'm having to work with a native, buggy Javascript code (again!) and somehow Shadow/CLJS is behaving strangely. From what I could get, some namespaces simply change to undefined and I can't call function on them anymore - I start the "watch" process, connect my Javascript app, but as soon as it tries to run anything that's on the ClojureScript side, it simply fails with TypeError: Cannot read property 'after_load' of undefined for example (`after-load` is a function defined on CLJS side). I found out that if, just after I connect to the JS app, I reload a specific namespace (by saving the file) then things work. Is there a way to either debug this issue, or force-reload of this namespace all the time?

Reading the docs but did not find any hints: Is it possible to swap out the version of clojurescript shadow uses? There's some 1.11 features I would like to try