search

elmish / Elmish.WPF

Static WPF views for elmish programs
Other
422 stars 68 forks source link

Debug tools #84

Open cmeeren opened 5 years ago

cmeeren commented 5 years ago

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

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 commented 5 years ago

Related: https://github.com/elmish/debugger/issues/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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago
  • 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 commented 4 years ago

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 commented 4 years ago

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.