Test and iterate on TS expandable hover apis

[mjbvz]

To try it:

• Build this TS branch and set it as your workspace TS version: Proposed expandable hover API TypeScript#59940
• In VS Code "typescript.experimental.expandableHover": true

Let's test out TS's current implementation of expandable hovers. The main question is if the UI is good enough as-is, or if it turns out we need something different, which may require API changes

[aiday-mar]

Tagging @gabritto about the following

I followed the steps in order to use the TypeScript compiler from the branch. Some feedback I have:

In the vscode repo on line 202 of the file contentHoverController.ts, hover on this._contentWidget, this shows an expandable hover. Expand it, this creates a big hover with the expanded type of the content widget. Aside from the fact that the hover is really long, which I am not sure can be avoided, I noticed several things:

• The hover content is cut off, with an ellipsis at the end. Either the editor hover cuts off content or TypeScript truncated the editor text. In this case I would have liked to see the full type.
• Curiously there is incorrect tokenization/colorization of the code in the hover. I am not sure if this is somehow related to the TreeSitter work that was recently done or if this has always been like this.
• As we previously discussed, it would be good to have clickable links that expand the hover instead of expanding everything at the same time. Expanding everything makes the hover unnecessarily long and hard to navigate.

Screen.Recording.2024-10-31.at.15.47.58.mov

I think it would be good generally to change the API so that we allow linkification of markdown text for the purpose of expansion. Perhaps in the coming iterations, I can develop this, if there is sufficient need for this to be put into the iteration plan.

cc @alexdima

[gabritto]

Tagging @gabritto about the following

I followed the steps in order to use the TypeScript compiler from the branch. Some feedback I have:

In the vscode repo on line 202 of the file contentHoverController.ts, hover on this._contentWidget, this shows an expandable hover. Expand it, this creates a big hover with the expanded type of the content widget. Aside from the fact that the hover is really long, which I am not sure can be avoided, I noticed several things:

• The hover content is cut off, with ellipsis at the end. Either the editor hover cuts off content or TypeScript truncated the editor text. In this case I would have liked to see the full type.
• Curiously there is incorrect tokenization/colorization of the code in the hover. I am not sure if this is somehow related to the TreeSitter work that was recently done or if this has always been like this.
• As we previously discussed, it would be good to have clickable links that expand the hover instead of expanding everything at the same time. Expanding everything makes the hover unnecessarily long and hard to navigate.

Screen.Recording.2024-10-31.at.15.47.58.mov
I think it would be good generally to change the API so that we allow linkification of markdown text for the purpose of expansion. Perhaps in the coming iterations, I can develop this, if there is sufficient need for this to be put into the iteration plan.

cc @alexdima

Thanks for the feedback. I removed truncation of the hover content on the TSServer side when expandable hovers are requested, so I think that's happening on the vscode side.

[aiday-mar]

I see thanks for letting me know, I'll have a look to remove truncation of hovers. I will discuss this issue with my manager to see if we should place the linkification of markdown text into the iteration plan and work on it.

I suppose also we could do a test pass on this perhaps during release week to get feedback about this.

[aiday-mar]

Hi I discussed this with my manager. Could we merge and publish the TypeScript branch work to production so we can self-host easily on the work in VS Code?

[DanielRosenwasser]

Hey @aiday-mar, the PR was merged yesterday afternoon. You all should be able to pick it up in the current nightly (5.8.0-dev.20241106), but let me know if there are any issues with that.

[aiday-mar]

Hi @DanielRosenwasser thanks for letting me know, I will upgrade the TypeScript version

[aiday-mar]

Here is the list of feedback I received. I will update this list as more feedback is received:

• Make the +/- button stick to the bottom of the hover part in such a way that it is always visible. The +/- buttons would scroll with the scrollbar and would clip to the top or the bottom of their respective hover parts.
• Increase +/- button size

[mylesmmurphy]

Hey @aiday-mar and @mjbvz! Really great work on this. I am the owner and maintainer of Prettify TypeScript, which provides similar functionality for TS types as an extension today. Needless to say, I am hyped to see this coming built-in as part of VS Code. Really great work 👏

I've been playing around with TS 5.8 and expanded hover option and have a few questions / feedback 😄

1. +/- Location: The location of the +/- feels a little off from a UX perspective. It feels inconsistent suddenly having a column on the left hand side pushing the information I care about to the right, with a bunch of white space filling up the area my eyes immediately go to. Also, when there's a lot of content that makes a scroll appear, it kind of starts to feel like I'm looking down a bowling alley with the 3 columns, haha. I personally think it would make sense to include these either in the Code Action menu, or on the right hand side, pushed below the scroll bar.

2. Intersections: One of the biggest use cases for my extension is developers like to see intersected types merged into one preview, instead of seeing the } & { clutter the view. See the difference between the two options below.

Current behavior:

Desired behavior:

If this is not desired behavior, I have already created a branch of my existing extension to provide this view instead, which may be the future of the Prettify TS extension. 😄

3. Object Prototypes: A lot of the feedback I receive on my extension is to hide object prototypes, and expand only the information that the end user cares about. In the example below, the highlighted area is the content most users have said they really care about:

That being said, figuring out and handling all the possible scenarios has been a massive pain in development of Prettify, and I can understand descoping it from this functionality. My extension currently displays the following (depending on user settings):

4. Timeline: If possible, would you be able to share the rough timeline on when this will be released? I am trying to determine if Prettify should continue to be maintained. I see 5.8 is slated for Feb. 25th release, will this functionality be released as experimental as part of that?

Thanks for all your help, and again thank you for your great work on this! This is exactly what many have requested in my project and I am so excited to see it moving in this direction.

Edit:

5. Default Verbosity: I know for myself and many others who use Prettify, it would be great to be able to set a default verbosity / depth level. For myself, I'd set it likely to 1, so that I can immediately see what properties are available instead of needing to click to drill into the information I'd like to see. In it's current implementation, I can foresee myself clicking the + constantly haha

Edit 2:

6. Instant Close Bug: Not a huge deal, but running into a little bit of buggy behavior when expanding near the top of my editor and my cursor lands on a different actionable item

Screen.Recording.2025-02-10.at.12.27.57.PM.mov

[gabritto]

@mylesmmurphy thank you for the feedback. The current plan is to have a first implementation of expandable hover ship with TS 5.9, and 5.9 beta should be out mid-April.

[aiday-mar]

Hi @mylesmmurphy thank you for the feedback. We will take into account the feedback concerning the positioning of the + and - icons. Once the first implementation is shipped, we will turn it by default on VS Code Insiders.

With the current API, I am not sure if we can have a default verbosity level setting. I will wait for more feedback and perhaps if there is more interest, we could rework the API.

Thanks a lot for letting me know of the rendering bug.