👋 Hello, and thanks for such an amazing project!

I've been interested in figuring out how to suppress the default (No heading) headers when using group by header, and poking around in the codebase revealed a number of possible approaches.

Before going too far in any direction, I wanted to socialize this feature a bit and get some thoughts from the maintainers.

Here's a quick visual of the problem I'm looking to solve...

...and a markdown representation of the task list (the file is titled A Sample Note):

- [ ] a task without a header
- [ ] another task without a header

## New Header 1
- [ ] task 1
- [ ] task 2
- [ ] task 3

## New Header 2
- [ ] task 4
- [ ] task 5
- [ ] task 6

In general, I'm curious to hear if this is something you'd consider worth addressing, and if so, whether the design decisions would have any bearing on some of the other grouping defaults (tags, folders, etc).

I spent a little time prototyping solutions and landed on a couple approaches:

Approach 1: using CSS to stay unobtrusive

My first thought was "the least destructive way to do this could be adding a new class name to elements without headings".

Something along the lines of:

<div>
  <h4 class="tasks-group-heading">Folder/Subfolder/</h4>
  <h5 class="tasks-group-heading">Filename</h5>
  <h6 class="tasks-group-heading tasks-group-heading--empty">(No heading)</h6>
  ...
</div>

Which folks could target and hide with custom CSS snippets:

.tasks-group-heading--empty {
  display: none;
}

The downside to this is that at the point in the code where we'd add this new class, it looks like the only way we can tell if a header is empty is by string matching against the value (No heading).

So in here...

...you'd be adding something like this towards the bottom:

if (heading.name === '(No heading)') {
  header.addClass('tasks-group-heading--empty');
}

Not terrible, but matching against string literals is a bit of a code smell and warrants some more thought. Also, leveraging this would require users to have familiarity with inspecting the Obsidian DOM and writing custom CSS.

Approach 2: skipping creation if the header is empty

My next thought was "I wonder if this is actually a desired default from a UX perspective". What if we just skipped making elements for empty headers?

It seems like if you were adding headers to a list of tasks, its reasonable to expect the document they're contained in would enforce an outline format. So something like this...

# Title

- [ ] task 1
- [ ] task 2
- [ ] task 3

## Header 1

- [ ] task 4
- [ ] task 5
- [ ] task 6

## Header 2

- [ ] task 7
- [ ] task 8
- [ ] task 9

...would naturally get grouped together and displayed in that same format. And something like this...

# Title

- [ ] task 1
- [ ] task 2
- [ ] task 3

## Header 1

- [ ] task 4
- [ ] task 5
- [ ] task 6

## Header 2

- [ ] task 7
- [ ] task 8
- [ ] task 9

- [ ] task 10
- [ ] task 11

...would consider task 10 and task 11 to be grouped under Header 2 (rather than a new group with no header).

It looks like the plugin enforces this as well, so I'd be curious to hear if there are any cases where not creating header element for empty headers could be problematic.

Unfortunately, we probably can't ship a lightweight solution here without relying on the same type of string matching in the first approach, which turns this...

...into something like this:

    private static addGroupHeadings(
        content: HTMLDivElement,
        groupHeadings: GroupHeading[],
    ) {
        for (const heading of groupHeadings) {
            if (heading.name !== '(No heading)') {
                QueryRenderChild.addGroupHeading(content, heading);
            }
        }
    }

Alternatives to String Matching

I explored two different ideas here, and both had discussion-worthy drawbacks:

Returning null when headings are missing

If this...

...turned into this:

    private static groupByHeading(task: Task): string[] | null[] {
        if (
            task.precedingHeader === null ||
            task.precedingHeader.length === 0
        ) {
            return [null];
        }
        return [task.precedingHeader];
    }

Functionally it works as expected, but a lot of type definitions throughout the code would need to change accordingly, which makes me think it's either not a good idea to introduce a null type by design, or refactoring could be a heavy lift.

There's also the question of whether we'd need to consider applying this pattern to other group types as well.

Storing default strings as constants

We could make string comparison less brittle by storing the default group strings as constants...

export const EMPTY_TAGS = '(No tags)';
export const EMPTY_HEADING = '(No heading)';
export const MISSING_FILENAME = 'Unknown Location';

... and importing and referencing those values instead:

import * as groupStrings from 'path/to/groupConstants';

if (heading.name === groupStrings.EMPTY_HEADING) {
  header.addClass('tasks-group-heading--empty');
}

I didn't see this pattern anywhere else in the code, and since the approach it introduces is pretty broad, it strikes me as the type of architectural decision to leave to the maintainers.

Definitely a more lightweight option, but opens up questions about what should be a constant and what shouldn't, and whether committing to that pattern means refactoring other areas of the code.

I'd love to hear what folks think — is this a feature that's worth exploring? If so, are there technical approaches to solving it that I may be missing? If we do land on something that warrants a PR, I'd be more than happy to contribute!

Thanks!