Feature: Per-item render customization for @pierre/trees

[tanvesh01]

Prerequisites

• I have searched for duplicate or closed feature requests
• I have read the contributing guidelines

Proposal

Please add a per-item render customization API for @pierre/trees (e.g. renderItem / item slot) so consumers can customize how each file/folder row is rendered while keeping built-in tree behavior.

Motivation and context

I need richer tree rows (badges/metadata/actions). Current customization seems limited to styling and icons, and a full custom tree means re-implementing behavior that @pierre/trees already handles well.

If this sounds aligned with the project direction, I’d be happy to open a PR : )

[SlexAxton]

Hi! Thank you for checking out trees. I think we're on the same page. I currently have been reluctant to add this feature in the existing codebase due to the large effect it has on render perf in common cases. I wanted to try to avoid footguns and breaking changes while the library was still in ~private (but publicly visible) beta.

That said, I'm currently in the process of rewriting more or less than entire core of the library so that we can better support this feature. I'm hoping for a timeilne of around the end of this week to switch over the implementation to the new core. I am hopeful that in this new world I can give more of the rendering over to the implementations without concerns.

For slightly more details in random order:

• the current implementation supports fully synchronous, unvirtualized rendering. so it was easy for someone to do a baseline integration and accidentally be calling their render functions tens of thousands of times.
• i'm also currently trying to hyperoptimize the html size and dom structure, so i was worried that i would introduce a bunch of breaking changes
• we use a web-component under the covers, and support ssr. so the only way we can do this with ssr support is to support a unique <slot> for every single item in the tree, which would be prohibitively large.
  • i think v1 of this feature will likely not support ssr, or more specifically it will work along side ssr, but won't be included in the initial renders
  • in the future i think we could figure out a way to make ssr work with slots + virtualization
• the new core of the library is an always virtualized setup, so we no longer will need to support non-virtualized use-cases.

All that to say, I'll keep this open and update it when I get something worth trying out in place. It's definitely a goal, I just want to do it well so it doesn't degrade the other features.