Hacker News new | ask | show | jobs
by tekacs 352 days ago
I was in the audience, asking the question at the end of the video!

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

2 comments

Shadow-cljs offers partial solutions to this with its runtime code reloading capabilities and source-maps in production, though true REPL attachment to production builds remains challenging due to the optimization/debug information tradeoff.
I'm not sure what "REPL attachment to production build" would look like in terms of a client-side program like this?

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.

What do you mean by re-hydrate?