ClojureScript from First Principles [video](youtube.com) |
ClojureScript from First Principles [video](youtube.com) |
I didn't quite get the question across and got an answer to a different question, so to re-state my actual question (that I asked David later), I was curious how heavy a lift it would be to preserve enough information in production ClojureScript compilation to allow re-hydrating. The aim being to re-hydrate enough in production that e.g. in the event of issues or errors, you might attach a REPL to that production build and poke at it.
The answer (which I mostly knew/expected) is... quite a heavy lift. I can imagine some possible solutions, but I'm mostly-Rust nowadays, so no solution from me soon. :)
I also really recommend the other [1] talks [2] from this event!
[1]: https://youtu.be/8K4IdE89IRA (Aaron, on using lenses, this sorta stuff [3])
[2]: https://youtu.be/fcSJAuUGVs8 (Ben, on a core.async error handling strategy that I had totally missed and totally changes the ergonomics of using c.a!)
[3]: https://github.com/tekacs/factor/blob/master/src/factor/lens...
Usually what I do in my ClojureScript programs is saving all the actions the user do into localStorage, offer a "Report Issue" button that shows a form with a description input, and submitting that form also submits the data from localStorage. Sometimes I also include the full app-state in there too, but often isn't even needed if the application is simple enough.
If you're using libraries like re-frame or similar, you basically get that for free, just need to persist the events somehow and associate them with a session/user.
So replicating issues that happened in the production build is a matter of replaying those same actions locally. Don't remember having any issues with this approach, and if you end up in the scenario where the same actions only trigger an error in the production build, then run that build locally but with sourcemaps and you'll be able to track down the issue quickly enough.
Today we also have sci/scittle/cherry for anyone who's seeking that runtime Clojure->JS eval vision. And now with Jank (LLVM Clojure) on the horizon this year it's never been a better time to try Clojure, regardless of which hosted runtime you're enthusiastic to use - Basilisp on Python, ClojureCLR, ClojureDart etc.
[0] https://swannodette.github.io/2015/07/29/clojurescript-17/
Now I’m SUPER excited to try cljs!! It’s crazy how modern it is despite being kinda old in webdev terms
The [Closure Library](https://github.com/google/closure-library) is done.
Very confusing, I know
I don't use Atom or Visual Studio Code today, nor much JavaScript, and my most-used language kind of gives me this for free nowadays (ClojureScript) but I expected there would be entire businesses today offering the functionality I built back in 2016, but as a all-in-one package with even more bells and whistles. There is so much we could do to make the experience better.
It seems to me like "interactive development" is just a thing for some section of programmers. Personally I couldn't live without my repl-connected editor, but judging by the amount of people who live and swear by the "edit -> compile -> view -> repeat" loop they spend all day doing, it seems like not everyone is wired the same.
Most of us (developers using ClojureScript) are using React or similar "view-as-a-function" libraries, where the UI is essentially built from pure(-ish) functions.
I'm using the REPL as effectively with ClojureScript + Reagent as I would with any Clojure program. The only thing that matters is how you structure your application, and it's certainly possible to iteratively develop frontend applications with ClojureScript just like what we do with Clojure.
Personally I split those things up into two parts, and only iterate on the UI with "static data" that either exists before, during or after. So testing/iterating on things like "Click button, loading animation plays while network request is in flight, show success/failure" is essentially 4-5 "static" states, and you don't really have to care about what happens in-between much except for corner-cases.
Oh, but we do this in ClojureScript the whole time.
You can express events and actions in pure functions as data and then take care of the effects outside of the core of your application.
A great example of how to do this is the "re-frame" framework [1] [2]. The documentation is also a joy to read.
> An example of this impedance surfacing in backend programming is a nontrivial map/reduce pipeline. What is the shape of the document at stage six?
There's many ways to find that out in Clojure/Script. There's the built-in `tap>` function [3] which can be used for debugging. You can use that to visualize complex data with Portal. [4]
(defn inspect
[coll]
(doto coll tap>))
(->> coll
(map this)
(inspect)
(filter that))
[2] A library with HTTP-Effects for your re-frame applications: https://github.com/Day8/re-frame-http-fx
A one way to address that is via tooling (e.g. to visualize state across time) but maybe there’s something more fundamental to be solved here? Or is it more about current tooling capabilities?