Debugger: Grouping msg

[jinjor]

This PR adds "Grouping messages" feature to the debugger.
(Most of discussion are done with Evan.)

Group by sequence of constructors

• ComponentMsg 1 (Transition 1484006671635)
• ComponentMsg 2 (Transition 1484006671635)
• ComponentMsg 1 (Transition 1484006671737)
• ComponentMsg 2 (Transition 1484006671737)

These four are grouped by “ComponentMsg … Transition”, only seeing the constructors and skipping any other information.

Only frequent messages are hidden

The open/close state for each group is automatically determined.

• grouped frequent messages such as Tick or MouseMove are hidden by default
• grouped but not frequent messages such as Clicks are shown by default
• Currently, the threshold is 120ms.

[process-bot]

Thanks for the pull request! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[jinjor]

@evancz
I have this test too, but there are some problems.

• The current test worth keeping? (It is for 0.16...)
• This issue (from elm-package)
  • elm-package fetches elm-test's /example directory, and virtual-dom package conflicts
  • Maybe other people will fetch this repo's /tests directory too?

[jinjor]

Seems like CSS is messed up. I've already found the cause. Will be fixed soon.

[jinjor]

Oh, I forgot to mention the trade-off of this implementation.

Unlike before, the number of messages in a snapshot is flexible now. If all messages belong the same group, the snapshot will be infinitely growing. For example, just seeing 60fps game 10 seconds will make 600 messages. So unlucky user may have a very bad performance.

That said, I guess the current state of such game development is "cannot do any debugging". I think getting more feedback from them is higher priority.

The workaround would be maxGroupLength = 100 or something. This will divide one group into many and makes the view a bit ugly, but avoid the worst case. Is this worth trying?

[evancz]

I wouldn't do more optimization on groups for now.

If you have better tests, swap them in.

[jinjor]

Done. I found a workaround for package conflicts, so it is no problem.

[rtfeldman]

It's generally best pin this to the current version, e.g. npm install -g [email protected] - otherwise these tests will start failing once 0.19 is released.

Granted, it's safe to assume this particular library will be updated before that happens, but some people will probably copy/paste from this config, so it'd be nice to them if this did the better thing. 😄

[jinjor]

Thanks, I actually did copy/paste from somewhere. Just updated!

[jinjor]

I will close this because this is outdated.

It would be great if this debugger supports grouping, model diffing and other things like that, but I cannot spend my time to do them. Also, I felt a lot of pressure to break official tool and respond to everyone's needs.

So I think it's far easier for me to maintain my code for my purpose. I will plan another way to contribute to Elm. Sorry ;)