Running 2.2.4, I’m seeing #shadow-hud-loading-container but not seeing #shadow-hud-container if I force a syntax error (just an error in the terminal). Was the HUD changed in some recent version? (I upgraded from a 2.0.x version)

@pithyless didn't change the HUD in a while no (and its working as usual for me)

random cljs repl question. Quite frequently for whatever reason I get a “REPL Timed out” error (maybe caused by a syntax error or something else). Is there something I should try other than restarting the whole shadow-cljs server to get it working again? refreshing the browser page usually doesn’t work, nor does re-opening a new nrepl connection

restarting should never be required

I recently added (shadow.cljs.devtools.api/reload!) to "restart" the server without restarting the JVM

but I'd like to hear more details about the timeout

probably a bug somewhere

although one repl timeout shouldn't break the entire connection

hmm

i’ll see if i can reproduce something easily

REPL command timed out. is the error?

that is common yes

right now i am already in that state, and I am trying to evaluate :cljs/quit, i see

Error evaluating - class java.lang.InterruptedException: 
Error evaluating - class java.util.concurrent.RejectedExecutionException: Task [email protected] rejected from [email protected][Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 4]

hmm did you by any chance call shutdown-agents?

i don’t think so no

wait

let me restart, i don’t know when i quit the node process

so ignore this last bit

rejected means that the pool was shutdown which shouldn't happen during normal eval

only thing that would do that is shutdown-agents

yeah I think while we were chatting I had already started going through the motions of restarting the thing and forgot

so, if I get the timed out error, I should try to :cljs/quit and then (shadow.cljs.devtools.api/reload!)

first I'd like to know the form that caused the timeout

try to eval something simple like (+ 1 2)

then quit/reload maybe

ok

is the timeout legit? do you do something that actually takes a long time?

no, I think it usually happens when there is some kind of evaluation error

i will play around and see how i can replicate

is there a flag to make the development server log requests, perhaps in one of the common log formats?

not currently. why would you want that?

it would be like hundreds of JS file requests. not very interesting?

debugging. sometimes static resources load funny, or i have some kind bug with the way i’m manipulating client-side html5 history. it is nice to know sometimes when my app is actually hitting the server and what it is requesting

don't the chrome devtools tell you that?

allegedly they do.

i can’t figure out why i am apparently loading an image successfully but i get a broken link image

are you sure the image is getting loaded? I mean with push state you get success for everything although it always the index.html

the other issue i have is when i’m not at the root level and I manually refresh, the development server doesn’t reserve the app like i would expect

sounds like you are using <script src="some/relative/path.js"> maybe?

I guess I just wanted to sanity check what the hell was going on by checking the server logs. But you are right, there are other ways to debug this.

<script src="js/main.js"></script>

use /js/main.js. otherwise it will attempt to load something/js/main.js when you are in /something/path

oh.

yup that fixed it. 🙂

the error that happens is truly inscrutable

well yeah because you don't get 404s when using pushstate

maybe I could 404 when .js files are requested

this is also the problem with my images not loading

unlikely you are going to use that in html5 history paths

chrome devtools thinks the request was successful

in chrome you can click open in new tab for the request

or look at the response preview

if its html its not an image

but in general always use absolute paths to avoid such nightmares 😉

create-react-app handles this problem really well. i think they look at the headers. they also have a very convenient proxying feature so that development and deployment look similar when you server the bundle from the api server: https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/README.md#proxying-api-requests-in-development

i think it is related

guess I could check the headers

i have dreams of building c-r-a on top of shadow

hehe why? or which part?

because I think its the right way to get an opinionated set of tools going and get people interested in cljs development

should I just make the push-state thingo the default? kinda feels like it might be the "usual" thing you want for a cljs app

templates are terrible and once you use one you can never keep up to date

true but whats missing?

I'm not buying the whole zero-conf argument. I think thats actually a bad idea

you just get so much functioning stuff for free with create-react-app. just look at the user manual.

development, production, testing, instructions on editor integration

zero-config really helps get you going and focusing on what matters

you can always eject and customize when you get sophisticated

in my experience, people overestimate the value of customization and underestimate the cognitive load needed to make decisions

it is great if you are an expert, but it sucks otherwise

so much of the cljs experience is still in the “use the source, luke” phase

you just won’t get anybody but hobbyists and top 1% programmers that way

even though I am a big fan of shadow-cljs and tell everyone to use it on slack, there is still something totally amazing about create-react-app. you npm install it, you create a new project, you say npm start, and BAM, you have a working hot reloading project. you can start editing right then and there. shadow is great, but you still have to go read the section on :devtools, pick a directory, make sure you’re setting it right, figure out how the :after-load handler works and install it somewhere, etc. etc. each of these things = friction.

if you want to do a little experiment in react, it’s super easy because you can just fire off a c-r-a, do some stuff on the main page, and then throw it away

also, shadow can’t really be opinionated about reagent vs. rum or what have you, whereas a create-reagent-app could

it could be opinionated about a testing framework

I'm all for making things easier especially for beginners but I do think that some config is important

I could certainly simplify the :browser target and introduce some convention around it

or add something like :browser-simple

ie. just set :app-ns my.app or so

from that is infers my.app/start and my.app/stop as the :after-load and optional :before-load

always creates an public/js/main.js

so no :modules

testing I have something in the works that makes it zero conf

zero config should be thought of more like “sensible defaults for generic things that most people will want”

even with c-r-a you can eject. the only reason they did it that way is that it allows them to update the toolchain from underneath you, which is totally rad.

well thats the idea behind shadow-cljs in the first place

and i think you’ve largely succeeded. the thing is that c-r-a does that one level up on the stack. it picks react, a testing framework, a bundler, give some options for addons like less/sass, etc.

true

well there could always be :target :reagent

:browser is just generic browser stuff, could totally do framework specific stuff

not inside shadow-cljs itself but add one dep you are good to go

one thing that create-react-app did which is quite clever is that they separated out create-react-app, which is a generic tool, from react-scripts

i wonder if shadow-cljs might be able to act as create-react-app and then you could write the react-scripts equivalent for, say, reagent.

some people just fork react-scripts if they want quasi configuration capabilities. and others have react-scripts variants available

well the create-react-app part is just a template really.

just most of the template is hidden in react-scripts rather than the template itself

https://medium.com/@denis.zhbankov/maintaining-a-fork-of-create-react-app-as-an-alternative-to-ejecting-c555e8eb2b63

right that’s what i mean.

I absolutely hate templates as well

for this very reason

they just get out of sync and then you are F*

yea and you have no idea what’s going on

this is a big reason why i think lein ended up hurting the community. people made stuff that is complicated and undocumented but hid it behind a lein template

its almost too powerful

{:source-paths
 ["src"]

 :dependencies
 [[reagent/shadow-cljs "1.0.0"]]

 :builds
 {:app {:target :reagent
        :app-ns my.app}}}

this is totalyl doable today without me doing anything

so what would that script refer to? like, would it know to download something and then run it?

the "script" just generates that config

and creates the matching package.json

then runs npm install and prints the usual help stuff

and of course all the src files

i’m confused. i don’t see any documentation on a :reagent target in the guide. are you saying one can create custom targets?

yep, custom targets

https://shadow-cljs.github.io/docs/UsersGuide.html#_custom_targets

not well documented but you can just delegate to the :browser target for everything in this case

oh cool

basically just generate the usual :browser config from that :target :reagent baseline and call the browser/process fn

bascially what :reagent means is that shadow-cljs will try to load shadow.build.targets.reagent/process

https://github.com/thheller/shadow-cljs/tree/master/src/main/shadow/build/targets

this is great! i never really grokked this but shadow-cljs does really emulate c-r-a in structure

all the default targets are built this way

i mean maybe you came first, but you know what i mean

I might need to make a few adjustments to the devtools http stuff. this is not as flexible as I'd like it to be.

but apart from that everything should work just fine

@hlolli already created a basic chrome extension template this way. https://gist.github.com/hlolli/265b9183566a4c5829d7ee355e3d0998

which is basically just :browser with one adjustment to only output a single file in development

to write cljs and target whatever chrome needs for its extensions?

only the JS part the manifest you still have to write

but you could also generate the manifest from the shadow-cljs config no problem

I do want all these targets to exist, eg. :electron, :react-native, etc

just have limited time to create/maintain them

but they totally do not have to be part of shadow-cljs itself

would it work if you publish them to clojars and then add them as a dependency?

{:source-paths
 ["src"]

 :dependencies
 [[reagent/shadow-cljs "1.0.0"]]

 :builds
 {:app {:target :reagent
        :app-ns my.app}}}

thats the [reagent/shadow-cljs "1.0.0"]

oh i see

can't add it as a dependency to shadow-cljs itself since that would be circular

also it would make you a gatekeeper of sorts. much better this way so people can just do whatever

exactly 🙂

i have read of companies forking react-scripts privately so that they can keep their configuration separate and shared internally among their own projects

yeah you could totally do that with shadow-cljs and a custom :target

maybe there are other ways to "extend" things I just didn't think of yet

shadow-cljs clj-run reagent.quick-start

some clojure ns that does all the bootstrapping and starts whatever you need

well i’ll play with this a bit later. i think its a neat idea

a more focused :target could definitely set way more aggressive defaults than :browser can. and since its just clojure data you could just generate the more complex :browser config from the "easy" one.

@lee.justin.m just pushed 2.2.5 which makes push-state the default and does the Accept header check to no longer serve images as html

very nice! thanks