Debug tools

[cmeeren]

I would be great to create some debug tools such as:

• Time travel debugging (Does time traveling work?  #4)
• Logs displaying messages, state, and state diffs
• Visualizing the binding tree and which bindings are triggered for each update (to more easily see points of optimization using lazy - "hey, why are those bindings in that unrelated part of the app triggered when I edit this text field?")

This can probably be done by starting another window controlled by Elmish.WPF. Can be configured to start using ElmConfig.

Redux DevTools can be an inspiration for functionality and/or UI.

[et1975]

Related: elmish/debugger#7

Redux DevTools could actually be more than just the source of inspiration, it has stand-alone monitor that could be be used "as is" if we had the protocol implemented over TCP.

[cmeeren]

Thanks, I'll keep that in mind. I might go for a simple proof-of-concept in pure .NET just to get something useful out quickly (if/when I decide to start working on it).

[cmeeren]

I experimented a bit, but couldn't get anything good going. Leaving this for now, with no immediate plans on taking it up again. Anyone is welcome to work on it.

On a related note, I have just added performance logging to the wip-3.0 branch. It allows you to easily see in the console/trace which binding calls are taking a long time.

[TysonMN]

• Logs displaying messages, state, and state diffs

The logging of those three things should occur in Elmish instead of Elmish.WPF since they are independent of WPF, right @cmeeren?

I have been analyzing the logging in Elmish and Elmish.WPF and will create issues in each project soon to discuss what improvements could be made and what changes the maintainers are willing to accept.

I enjoy thinking about and making the development process more efficient, so I am excited to work on all three issues you listed (though, not all at once and not immediately!).

[cmeeren]

The logging of those three things should occur in Elmish instead of Elmish.WPF since they are independent of WPF, right @cmeeren?

Well, you'd need some UI. I was experimenting with a custom Elmish.WPF-controlled window that displayed these things. But one could also integrate with external tools, such as the aforementioned Redux DevTools. That might be a good way to solve this, because it gives you a lot of info.

Looking forward to your contributions!

[TysonMN]

Ok, I understand now. Thanks for your explanation @cmeeren.

I created the issue I promised about my ideas to improve logging. It is issue #105.

I think about logging as happening in two steps:

1. creation of log events and
2. handling of log events,

where log events are just immutable data.

Now that I think of it, the creation of log events seems similar to the creation of messages in the Elm Architecture and the handling of log events is seems similar to the processing of messages by update, the commands its returns, and how this data is ultimately displayed by view.

In that sense, I believe that Elmish.WPF should primarily be in the business of creating log events. The processing and viewing of log events should be handled elsewhere. This is what I am talking about in my first suggestion in #105.

So we could build an Elmish.WPF-specific GUI logging sink, but I think we should first add support for any possible logging sink.