Are those downsides still valid today?

Learn
6

I don’t share that sentiment: Just look at what Debug.log model looks like when using the Elm debug helper extension (on chromium browsers, on Firefox it unfortunately is not as nice)


Image source: Nicer Debug.log console output - #14 by kraklin

If someone is open to using a browser extension like redux devtools or react devtools, one could also use the Elm Debug Helper extension by @kraklin (on Firefox and Chromium browsers).

Even if that is not an option, you can still use it directly as an npm package or by adding it directly to your HTML in all other browsers.

<script src="https://unpkg.com/elm-debug-transformer@latest/dist/elm-console-debug.js"></script>
<script>ElmConsoleDebug.register()</script>

There is also a lot of information on an alternate approach in this discourse post, following into the (archived) github repo, you will find e.g. this meta-issue for a ton of great information that I have on my reading list for a long time…

About the Elm time-traveling debugger

I think following statement from the medium post is misleading:

There is an Elm debugger (imagine Redux devtools) but that doesn’t work for our app so we can’t use it — using certain message types (think of Redux actions if you’re from React-land) cause the debugger to throw up.

I have never seen events that caused the debugger to “throw up”. In my experience it renders deeply nested message structures with a lot of arguments just fine.

I assume that the writer has hacked their Elm runtime using undocumented APIs to run “native” (or “kernel” since August 2018 brought us elm 0.19) code in a dirty way. Most likely to use a browser API that is not available in Elm with an effect manager, and did a poor job at it. If his dirty hack had been a little better, he would also have been able to get useful output in the debugger.

There is also a direct question to the writer of the medium post about his debugger issues one day after he created it, and he has not replied yet so I would not give it too much thought.

But looking into this recent writeup about effect managers might still be worthwhile, which also references Platform.sendToApp and the following official Elm documentation:

An extremely tiny portion of library authors should ever write effect managers. Fundamentally, Elm needs maybe 10 of them total.

Using unsupported APIs like WebRTC or WebSockets with ports or custom elements works just fine for me (and many others), see e.g. the official guide or beginning elm.
At my main project at work we use a binary WebSocket protocol and WebRTC for conferencing and screen sharing.
It definitely requires more thought and synchronization than directly writing JS, and that might be a reason not to do it, but I would not consider it a blocker.

Going back to the debugger, a coworker wrote this about a week ago:

Folks, I noticed that it’s possible to re-establish a [failed WebRTC] connection using the Elm debugger, moving through messages, that’s cool :smile:

This is possible because when stepping through the list of messages in the debugger, not only the neat elm model changes are visible, but also the dirty side effects are executed. (And because we use a media server that accepts the same SDP offer/answer again from the browser, but that’s beside the point).

Using the debugger with many subscriptions

I understand that the time traveling debugger might seem to not be very usable when you have many subscriptions (e.g. 60fps for an animation or game), but when paired with one of these approaches, I think one can still use the debugger to find bugs or trace the behavior.

  1. Manually open the debugger and use the slider to go back in time - subscriptions and other messages are paused until manually pressing play.
  2. Add a button to stop subscriptions (many games will anyway need a “pause” button)
  3. Add a port to stop subscriptions, so you can use app.ports.pause.send(true); in the browser console and then pass false to enable it again.
  4. Change the update function to disable the subscriptions if an unexpected state has happened (I like this one best during development)

I wrote a small example in https://ellie-app.com/cm6CzRLJKk4a1 that shows them (and the simple output of the elm debug helper).

4 Likes