livebook-dev / kino

Client-driven interactive widgets for Livebook

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Expand tuples in Kino.Tree by default

josevalim opened this issue · comments

Hi @stefanchrobot, what do you think about expanding Kino.Tree for tuples by default? Or for tuples with 6 or fewer elements? We often have 2 or 3 element tuples, and having to expand them manually makes navigation harder. :)

Sounds good! Should we apply the same logic to lists and maps? This would be nice for exploring API responses. Maybe we need something like "expand everything up to M elements up to Nth level deep"?

When building Kino.Tree I was considering adding some sort of UI elements for configuring this. What do you think about that?

I'd start with tuples right now. I would even always expand them by default.

The reason I am worried about also adding lists and maps is because you can have maps/lists inside maps/lists, so if we expand them by default, even if small, we can have a really large output, because we small maps inside small maps inside small lists.

Tuples are usually not nested within each other. :)

I hope to be able to take a stab at this issue this week.

Sorry for the delay, hopefully I'll get to this soon.

Wanted to follow-up on this. What do you think about making this customizable like on the mockup below? The settings could be stored in the browser's local storage.

Screenshot 2024-02-21 at 18 10 22

The idea here is that the settings represent an "or" condition, e.g. auto-expand if it's a tuple of size <=6 or we're at level <= 1. I think it would be nice to set a limit to the depth to which auto-expansion applies. Not sure how to represent that in the UI. I thought about a double slider for "depth", but it may be a bit confusing.

Do you think this would be useful?

I would wait until there is a use case.
I use Kino.Tree a lot (it is awesome) and I want to see how the latest changes work in practice. If we feel they need more tweaking, we can revisit. :)

Makes sense. My use case for Kino.Tree was for exploring API responses. Maybe if the REST smart cell get's more traction there will be a stronger need for adding settings.