Clojurians Log v2
nbb
New to Clojure. I wrote a little countdown alarm script based on the ink-demo, but when I tested it with 1000 hours, I encountered a JavaScript heap out of memory error. I found out that the code below was causing significant memory and runtime overhead.
(doseq [n (range 1 @left-time)]
(js/setTimeout #(swap! left-time dec) (* n 1000)))(def count
(js/setInterval
#(if (> @left-time 0)
(swap! left-time dec)
(js/clearInterval count))
1000))README for this?
@openefit please do!
Submitted, thanks for merging. By the way, nbb is really awesome!
Thank you :)
Working on a web framework for personal projects big and small. One big enhancement would be to auto-refresh the browser after sending data to the nrepl server. Are there any systems in place that would at least let me observe the eval request? Thinking if I could at least react to eval, I could broadcast a SSE to the browser to refresh in development mode.
Thanks! That’s exactly the kind of alternative I had in mind
You mean some kind of middleware thingie?
Oh yeah! I forgot nrepl supports that 😅 That would probably work!
well, nbb nrepl doesn't support it (yet)
also bb nrepl doesn't support it (yet)
I see. I'll start by reading through https://github.com/babashka/nbb/blob/main/src/nbb/impl/nrepl_server.cljs and see where that leads
I guess you could re-define your eval keybindings to something which evaluates + also adds a (broadcast ..) call to the mix in your editor
Oh right, something like that crossed my mind too. It's a viable alternative for personal use, but that would be a strong choice with the goal of publishing a framework
A quick solution I suppose would be to use something like browser-sync to watch cljs files, and refresh browser on save
Would it be possible to start a nrepl server via the api, then proxy it to intercept?
there is an nrepl api yes
On second thought, maybe auto-refreshing on eval is not a great DX. It's not uncommon to check state like:
(comment
@routes)Yeah that might work better: • Watch cljs files for changes • On save, connect to repl and eval the file, if successful send SSE to refresh • Server adds a script on dev mode to listen for those SSEs and triggers a refresh
Argh maybe not, (sorry thinking out loud), not every file save should be eval'd. So maybe proxy request, but try and distinguish between a form eval (don't refresh), and a buffer or file eval (refresh). I am pretty sure every time I eval'd a buffer or file, I immediately refreshed the page to look for changes.
For the middleware approach, is it critical it matches the existing nrepl middleware interface\implementation? In theory, it wouldn't be much work to create a promise-based ring-like middleware system for the nbb implementation
I already have the promise-based ring-like middleware for my request layer so copying that over would be fairly trivial.
I don't think nbb nrepl should be compatible with existing middleware since that's usually all based on JVM anyway, right
feel free to draft something
Awesome! This is what middleware usage looks like https://github.com/jaidetree/gracieanimator/blob/c2dbacaffd21cd4fb9a2323a2e70c3a0d1b50f7b/src/gracie/server.cljs#L14-L26 and most are implemented here https://github.com/jaidetree/gracieanimator/blob/c2dbacaffd21cd4fb9a2323a2e70c3a0d1b50f7b/src/framework/middleware.cljs
To get started thinking... 1. Clone latest nbb (or update my fork) 2. Add in middleware args and support it in the server API 3. Use npm link 4. Link this client project to it, start with some logging middleware to see what happens Does that make sense? One more question that comes to mind: Should we support middleware out of nbb.edn or is it ok to start without that for now?
probably makes sense
@jayzawrotny you might find this a useful reference too: https://github.com/chr15m/sitefox/blob/32d33aa723de9afa578efc4f35bcc8e2ddfbb7ae/src/sitefox/reloader.cljs#L10
It is not tested very well but last time I checked it was working.