I would have guessed the opposite: That adding this feature to the debugger would be easier since
Cmd are opaque.
You can use
update so you can never tell for sure which commands are sent.
This is a very interesting question! I’ve never thought about it before, but it does sound useful to see not just see the resulting model after each message, but also the resulting commands! I’ve added
Debug.log at commands before to see if they get triggered or not, so just getting that directly from the debugger does sound time saving. Similarly, it might be useful to see which subscriptions we have after each message, too!
It would guess this requires going through the Kernel (JS) code for all
elm/* packages and attach some kind of debugging information to the commands that they can produce, and probably only when the debugger is enabled (the compiler has support for switching between different JS code for dev/prod using comments).
Then one would need to update the browser/src/Debugger at master · elm/browser · GitHub code to display commands (and subscriptions), as needed (for example, not for
I have dug around a bit in the Debugger source code before, so it does sound possible but it’d take an answer from someone who has actually worked on it to get a more precise answer.