Handle large collections in Debugger #145
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 elm#90 Closes elm#104 Closes elm#132 Closes elm#120. That’s a previous PR that touched on this problem. That PR makes the experience go from crashing to awfully slow. 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.lograther 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.