Handle large collections in Debugger

[lydell]

Large collections, like lists with thousands of items, either cause the debugger and the whole application to be very slow, or crash with a stack overflow.

Closes elm/compiler#2133
Closes #90
Closes #104
Closes #132

Closes #120. That’s a previous PR that touched on this problem. That PR makes a function tail call recursive to avoid crashing, but the slowness remains.

This PR is fast even with big collections, by expanding just the first 100 items. There’s a “view more” button to show the next 100. I went with the simplest possible UX around that, since it’s unclear if anyone actually tries to click to item number 9000 – at that point, search is better. And then you could just as well do the search with Elm code and Debug.log rather than using some obscure search syntax in the debugger. I think looking at the model in the debugger is more for learning the overall structure of an app, than to look at every single item of long lists, sets or dicts.

Note to those following along: This PR is included in https://github.com/lydell/browser/tree/safe, which is part of https://github.com/lydell/elm-safe-virtual-dom, but it has nothing to do with “safe virtual DOM” really, it’s just in there because it’s convenient.

[ahankinson]

Applying this fix seems to crash the debugger?

I got an error:

app.js:59 Uncaught TypeError: fun(...)(...) is not a function
    at A3 (app.js:59:50)
    at _Debugger_init (app.js:4892:10)
    at _Debugger_init (app.js:4890:22)
    at _Debugger_init (app.js:4890:22)
    at _Debugger_init (app.js:4890:22)
    at Function.f (app.js:8122:14)
    at A2 (app.js:56:28)
    at Function.f (app.js:8657:6)
    at A3 (app.js:59:28)
    at $elm$browser$Debugger$Main$popoutView (app.js:9505:5)
A3 @ app.js:59
_Debugger_init @ app.js:4892
_Debugger_init @ app.js:4890
_Debugger_init @ app.js:4890
_Debugger_init @ app.js:4890
(anonymous) @ app.js:8122
A2 @ app.js:56
(anonymous) @ app.js:8657
A3 @ app.js:59
$elm$browser$Debugger$Main$popoutView @ app.js:9505
(anonymous) @ app.js:4593
drawHelp @ app.js:5153
updateIfNeeded @ app.js:5166
(anonymous) @ app.js:5112
requestAnimationFrame
_Browser_requestAnimationFrame @ app.js:5100
(anonymous) @ app.js:5186
sendToApp @ app.js:81134
callback @ app.js:3391

This was applying it on top of previous PRs in the elm-janitor/browser fork, and there was a merge conflict that needed to be resolved with, I believe, #142

[lydell]

Most likely a mistake in the merge conflict resolution then. I use this via the safe branch and it works.