RFC: inline code folding in HTML-like languages and frameworks

[niklas-wortmann]

Abstract

Sometimes, when exploring the code, it can become challenging to navigate through lengthy attribute values in HTML-like code (React, Vue, Angular, Svelte). This is especially common in style systems like Tailwind CSS, where class or className attributes often contain a list of classes, making code exploration more difficult. Once we realized this, we saw an opportunity to improve the code navigation experience for framework developers.

Proposal

The RFC suggests introducing a feature for JetBrains IDEs that allows three modes for managing inline code folding* in HTML-like languages and frameworks (JSX/TSX, Angular, Vue, Svelte, etc.) to improve code readability:

Strucure Mode: IDE hides the values of all attributes in a file, making it easier to explore the code structure.
Compact Styles Mode: IDE hides values specifically for class, className, and style attributes in a file.
Full Mode: This is the default, standard IDE mode with no inline folding applied.
*Inline code folding refers to collapsing parts of a single line, while standard block code folding handles entire code blocks like functions or classes.

• Mockup 1
  

• Mockup 2
  

To switch between these modes, we have several implementation ideas:
An icon next to the attributes when values expand on caret, available in Compact or Compact Styles modes.
An icon in the gutter when values expand on caret, available in Compact or Compact Styles modes.
Icons in the upper-right corner in the editor.

• We will provide a shortcut along with the UI solution (for example cmd+shift+, / ctrl+shift+,).

The inline code folding behavior introduces two main differences from block code folding:

1. Caret-triggered expansion: When the caret is placed on a line with inline folding, the IDE automatically expands it. The folding collapses again when the caret moves to another line.
   a. The mouse-triggered expansion works the same as in block code folding: When expanding folding with a mouse click, the expanded state persists after moving the caret away.

2. No collapse / expand arrows for foldings in the editor gutter: Code foldings arrows are shown by default in the editor gutter for all code foldings, it won’t be shown for inline code foldings to minimize the UI clutter;

3. Fold and unfold actions will respect the caret position within an attribute value. The caret placed outside the attribute value triggers familiar behavior where IDE uses the basic rules for folding block comments and tags.

What kind of feedback are we looking for?

We're looking forward to hearing your thoughts on this proposal! To help focus the discussion, we’ve outlined certain discussion points here. When providing your input, please specify which question(s) below you’re answering:

• Question 1: Should IDE change how attributes are presented in a file in Compact mode? For example, instead of displaying each attribute on a new line, IDE could place them on a single line to save vertical space.
• Question 2: How frequently would you switch between Structure, Compact Styles, and Full modes? In what scenarios would you do so?
• Question 3: Which of the proposed methods for changing modes would work best for you?
• Question 4: The IDE's default behavior could be set to Structure Mode or Compact Styles, making it easier to explore code when opening it for the first time. Alternatively, it could remain in Full Mode, as it is now. Which mode do you prefer?

[marksy]

Tbh, this is one of the reasons I dislike libraries like TailWind.

I don’t disagree with this proposal though, as long as it’s opt-in

[niklas-wortmann]

We used Tailwind here just as an example. The same would apply for instance if you have more complex JSX/TSX. Often the template has a lot of logic that doesn't change all too often, but it does negatively impact readability. The different mode can make code navigation much more efficient by hiding irrelevant information (at least that's what we are hoping.

But yeah the general idea is to have those 3 modes and define a default, but also allow changing it via keyboard shortcuts or similar.

[ericfortis]

What about something like the table on the MPS projectional editor?

https://youtu.be/XolJx4GfMmg?si=krNT8zHycaDcHwSr&t=63

for example, an obj or xml expands to a table (floating or inlined)
const obj = { foo: 1, bar: 2, baz: 3 }

foo	1
bar	2
baz	3

[niklas-wortmann]

Truth be told, I haven't considered MPS projectional editor yet and also I don't have a whole bunch of experience with it (literally zero :D) I will discuss this with some colleagues and get back to you in a few days. But thanks a lot for bringing this to my attention!

[hrmoller]

I really like the idea of providing a presentation of the code that focuses more on structure, leaving out details that likely aren’t relevant when scanning through the overall layout of the code.

To benefit from such a feature, it’s important that switching between the different modes is quick and seamless — ideally available both via UI buttons and keyboard shortcuts (which I believe you’ve already mentioned in the proposal).

Since I haven’t had the chance to try it out yet, it’s hard to judge how it will feel in practice. One thing I could imagine being a potential issue is a lot of UI “jumping” when switching modes. For example, if I’m looking at line 100 in Structure Mode and switch to Full Mode, the layout shift could move that line out of view. I’d expect the IDE to preserve my scroll position — ideally keeping the same line (or a relative position) centered so I don’t lose my place.

Another idea that could be useful is something similar to the magnifying glass feature currently in WebStorm. When hovering over the vertical scrollbar, you get a ~10-line preview of that part of the file. It might be helpful to have something similar for this: when I hover over a folded section in Structure Mode, I could get a peek at the hidden content in a small popup or preview window. There are probably other UX patterns that could work too, but the ability to get a quick look at the hidden details — without switching modes — would be handy.

---

Answers to your questions:

1. I think it’s totally fine for the IDE to show all attributes on one line — as long as it’s a visual-only presentation and doesn’t affect the actual code (e.g., formatting or linting rules from ESLint or Prettier).

2. I’d probably use Structure Mode when doing high-level navigation to understand structure and flow, and switch to Full Mode when writing or editing code. Compact Styles might also be handy when working on logic — then switch to Full Mode when focusing on styles. It’ll depend on the context, but Tailwind is a great example of where this feature could really shine.

3. As mentioned above, it depends on the situation, but I suspect Compact Styles could end up being my most-used mode.

4. I’d definitely want to configure the default mode on a per-project basis. I can see all three modes being the best choice depending on the type of project or even the team’s preferences.

[niklas-wortmann]

Wow this is fantastic feedback, thank you so much!

Yes we generally intend to have various ways to toggle between the modes as seemless as possible (UI and keyboard shortcuts).
The scroll position is very important and I will make sure to properly consider this in the final design of the feature.

About your preview suggestion:

Caret-triggered expansion: When the caret is placed on a line with inline folding, the IDE automatically expands it. The folding collapses again when the caret moves to another line.

Do you think that would be sufficient, or do you think hovering and having the code in some kind of modal/popup would be additionally beneficial?

[hrmoller]

Sorry for the late reply.

I might have missed it when I first read the proposal, but my initial impression is that what you described could be sufficient. I think a lot depends on the look and feel when navigating through the code—it’s hard to say for sure without trying it out. That said, your suggestion sounds like a solid first iteration of the feature.

[AbbasSrour]

I'll maybe go over the three other answers in more detailes later, but for question 3, I'd say I'll most likely be using the compact version by default, with moving the caret to classNames prop expanding it to view the tailwind classes. The biggest problem for me personally is tailwind, we have a strict no more than a one liner function passed to html attributes so the html for the most part is clean usually, only for the tailwind classes. I don't see myself really using the standard mode if this gets implemented.

[niklas-wortmann]

Thanks, appreciate the feedback 💯

[exsesx]

Hey!

This looks like an awesome idea – I’m all for anything that makes scanning code easier. If you haven’t seen it, the Tailwind Fold extension for VS Code does a great job with this. The way it folds classes with the Tailwind icon and the "..." is super clean, and the whole experience just feels great. Really helpful in day-to-day work.

Might be worth checking out how they nailed the UX – could save some time and UI/UX effort.

[niklas-wortmann]

That's certainly a great reference to look into the UX, I think our scope is a bit broader particularly with the structure mode, where it would also collapse event listeners and similar. But thanks a lot for sharing this, this kind of feedback on the UX is super valuable for us 🙌

[rChaoz]

I love this idea! Looking at the mock-ups, it looks like it would improve readability by a lot. This gives similar vibes to the structure window, which I use way less than I should. However, it's not great for deeply nested code (like HTML), so I don't think there's an overlap here.

As for the questions:

1. I think this should be up to the user, with an additional config option. One mode is much better for understanding the HTML structure, while the other minimises clutter while still maintaining the code aspect, so you can easily find what you're looking for, without causing major shifting whenever you move the cursor. I also think there should be a white/blacklist system for attributes, for example I don't think id attributes should ever be hidden. This would also cover the use-case where you may only want the class attribute to be folded.
2. Probably a few times a day, when I need to find a specific part to work on. I think it would also be useful when going through library files. A feature I find a bit similar is, weirdly, enabling/disabling text wrap in Markdown. We use no linebreaks in markdown paragraphs, so of course text wrap is always enabled. Except that it completely ruins tables! So when working with documentation with tables, I usually enable/disable wrap a few times.
3. Options 1 and 2 feel cluttered and might be confused with block-level folding. Option 3 feels most natural. As for auto-expanding the element where the cursor is, I wonder if it makes sense to have an option to expand attributes individually, but probably not.
4. Reader mode is awesome for libraries. But at the same time, it doesn't hide anything, just renders it differently. I'm neither for nor against this, just a thought.

[kricact]

Hi, thanks a lot for the thoughtful feedback!

[nilshartmann]

Looking forward to this feature 🤗

Question 1: Should IDE change how attributes are presented in a file in Compact mode? For example, instead of displaying each attribute on a new line, IDE could place them on a single line to save vertical space.

I would prefer to not change the alignment, as I think i can be hard to stay "focused" on the same code location when toggling the different modes.

Question 2: How frequently would you switch between Structure, Compact Styles, and Full modes? In what scenarios would you do so?

My biggest pain point currently (without this feature) are too verbose class/className-Attributes. So probably I would only toggle between Compact Styles and Full modes.

Question 3: Which of the proposed methods for changing modes would work best for you?

I would like to have a simple shortcut. I Also could imagine that (in Compact or Structure mode) clicking on a folded attributes expandes the attribute and let it expanded. So that one could collapse attributes by switing to Compact or Structure mode and then selectively expanding single attributes. Also when adding a new attribute that would be folded by the current mode, it think it should stay expanded.

Question 4: The IDE's default behavior could be set to Structure Mode or Compact Styles, making it easier to explore code when opening it for the first time. Alternatively, it could remain in Full Mode, as it is now. Which mode do you prefer?

As long as the IDE remembers my setting per file, I don't care otherwise I would remain in Full Mode, as that is the "obvious" mode for users that are not aware of the folding feature.

[niklas-wortmann]

Thanks for the feedback, much appreciated!

[Mati20041]

Hey! I'm thrilled that this is already an RFC, and I think this would be a huge UX improvement for more complex templates.

I'm also passing here my feedback from the Discord server. It is mostly React-related.

1. Compact Styles Mode: IDE hides values specifically for class, className, and style attributes in a file.

   I'd suggest the folded fields/props be configurable. For instance, in MUI the sx props are used for styling. In the mock example, I'd happily hide the transition prop too.

2. Compact vs Full mode sounds a bit like another option in "Editor -> General -> Code Folding". Perhaps we could have HTML-like section or more options for XML 🤔

3. One idea that came to my mind that would be very useful for my use case is a hybrid between Structure and Compact mode, where we could define which components are just a structure and which to display in a compact mode. ie:

• in MUI display <Box ...>, <Stack ...> as one-liners
• in styled-components approach - display <StyledXYZ> as one-liners
• domain's components - display in a compact mode (hiding only style, className, sx, and other configured props)
  Example of such a hybrid with Box and Stack listed to be structured only:

<Box ...> // everything folded to one-line
  <Stack ...> // everything folded to one-line
    <ProjectList 
      projects={myProjects} // not folded when inline object literal
      onProject={projectHandler} // not folded when lambda
      sx={...}/> // only sx folded
  </Stack>
</Box>

A nice reference for this is React Dev Tools, where you can filter out components based on type or regex of a component's name.

Thanks, and I can't wait for this feature to appear in the IDE!

[Mateusz-H]

General Feedback & Urgency
First and foremost, I strongly agree that this feature is a critical missing piece in the modern web development experience within the WebStorm ecosystem. The immediate need for this functionality is paramount, and I would advocate for its expedited release, perhaps initially as an experimental plugin with a limited feature set, allowing for iterative development and user feedback.

Positive Aspects of the Proposal
I am very pleased that this problem has been identified and that a solution is being actively pursued. The core concept of inline code folding, especially the caret-triggered expansion, is an excellent approach. I highly recommend examining the "Tailwind Fold" plugin for VS Code, as its implementation of caret-triggered expansion provides a very positive user experience that could serve as a valuable reference.

Suggested Enhancements and Modifications
While the proposal is a strong starting point, I have several suggestions for further refinement:

• Toggle for Auto-Collapsing/Expanding: While the absence of collapse/expand arrows for attributes is a good decision to minimize UI clutter, there should be an option to temporarily "expand/disable auto-collapsing" for all attributes via a keyboard shortcut. This would be useful for scenarios where a developer needs to view all attribute values at once, regardless of caret position.

• Configurable Attribute Whitelist/Blacklist: To offer maximum flexibility and customization, the feature should allow users to define a whitelist or blacklist of attributes that are affected by inline folding. For example, I might always want to hide className attributes but consistently display onClick listeners or certain SVG path attributes. This granular control would prevent constant caret movement for frequently accessed attributes.

• Attribute Name Hiding and Custom Icons: Drawing inspiration again from the "Tailwind Fold" plugin, consider providing the ability to hide the attribute name itself, displaying only a custom icon. This visual cue, similar to how "Tailwind Fold" presents a plugin icon instead of the "className = ..." text, would allow for rapid visual identification of an element's attributes (e.g., seeing three distinct icons for className, onClick, and another attribute) without the need to read the attribute name.

Regarding the questions posed in the RFC:

Should IDE change how attributes are presented in a file in Compact mode?
The IDE should not reorder or shuffle the position of attributes. Maintaining a consistent line number and order is crucial for collaboration and communication (e.g., "change line 34") and prevents confusion when discussing code with others whose IDE might display the same code differently.

How frequently would you switch between Structure, Compact Styles, and Full modes?
I anticipate rarely switching between these modes once I've configured the setup that best suits my workflow for a particular project. This suggests that the setting should ideally be project-based, allowing different projects to have different default folding behaviors.

Which of the proposed methods for changing modes would work best for you?
Option 3: Icons in the upper-right corner in the editor seems to be the most intuitive and accessible method for changing modes.

Which mode do you prefer as the default IDE behavior?
The IDE's default behavior should remain Full Mode. However, upon the feature's release, there should be a prominent, perhaps highlighted, mechanism to easily discover and change this setting, encouraging users to explore the new capabilities.

[kricact]

That's a good point about "a consistent line number and order is crucial for collaboration and communication". Thanks for the detailed feedback!