React Arborist – A full-featured tree component for React | Hacker News Reader

React Arborist – A full-featured tree component for React

github.com

210 pointsjameskerr53 comments

I should apologize off-the-bat for not digging in too deeply, but how does this handle keyboard and screenreader accessibility?

W3C has some in-depth list of expected keyboard interactions, though I'm not sure how complete they are:

https://w3c.github.io/aria-practices/#TreeView

https://w3c.github.io/aria-practices/examples/treeview/treev...

I ask because I've tried to implement a [TreeGrid](https://w3c.github.io/aria-practices/#treegrid) myself before and... it's a lot of work. I'd love an accessible, keyboard-friendly React tree :).

Thank you for bringing this up. It's I who apologize for being ignorant of these expected keyboard interactions. I'll make an issue in the repo to address this.

This is an interesting project that looks useful for making React components more accessible: https://react-spectrum.adobe.com/react-aria/index.html

"React Aria provides accessibility and behavior according to WAI-ARIA Authoring Practices, including full screen reader and keyboard navigation support. All components have been tested across a wide variety of screen readers and devices to ensure the best experience possible for all users."

Thank you! Don’t sweat not knowing, but without 100% accessibility coverage, the component might as well not exist — it could not be used in any publicly funded project in EU/USA or any commercial project in the EU, because it would be against the law to do so.

Nonsense. A deep study about web accessibility some 2 years ago revealed that 98.8% of web pages have accessibility issues. So saying "might as well not exist" is a dramatization of reality.

The significant majority of accessibility issues found by those sorts of large-range studies are comparatively minor, and often completely spurious. I have been decidedly unimpressed with every such study that I have delved into the results of.

(I know you’re arguing against someone claiming 100% accessibility coverage as a requirement, but I wanted to point out that figures like 98.8% are grossly inflated and quite meaningless.)

Those minor or spurious issues may well disable a disabled person even more.

That said, the entire accessibility scene is fundamentally broken on the technical side and full of snake oil salesmen on the business side.

Anxiously waiting for WCAG to finish an actual standard, and for vendors to actually implement it.

I’m well familiar with the issues of accessibility, and I use the words “minor” and “spurious” deliberately. Most especially, when I say “spurious”, I mean false positives.

I have yet to see a false positive. It might appear that way to someone only testing on a single platform, a single browser and a single reader, macOS + Chrome + VoiceOver for some reason being the usual combo even though VO doesn’t work right with Chrome.

Typically devs will also ignore reader shortcuts and instead use tab navigation, which is not how screen reader users do things because it bypasses screen reader navigation altogether.

Do you know for a fact that the ”false” positives weren’t actual problems for someone using NVDA or JAWS shortcuts to navigate on Firefox on Windows, or some other combination of reader + navigation + browser + OS?

Everything is broken and nobody can test or fix everything.

Not all web pages are owned by public or commercial entities. Those that are were not under legal obligations two years ago, but are now or are in the grace period.

> without 100% accessibility coverage

If that's the standard for open-source projects, it's a wonder any FE components get used

It is a legal requirement to provide equal access to all features and information for people who use accessibility features. Any non-trivial deviation from this must be declared in an accessibility statement, or the site owner risks legal action and large fines.

100% is not hyperbole, even though ”not exist” is.

As someone who has led WCAG remediation projects, I can firmly assure that it is hyperbole.

100% “accessible” is meaningless: full adherence to what standard? 2.1 AA? That’s an incredibly high bar, and would require constant vigilance and expensive audits on a rotating basis. Much of the guidelines are up for interpretation and can’t easily be expressed in a binary pass/fail besides.

2.1 AA is mandated by law in the European Union for public entities, as well as commercial entities (soon). And yes, it is a high bar, for a reason.

Just tried it with NVDA on Windows and it appears that it does not handle keyboard accessibility at all and does not communicate the relationships between nodes.

This is a great survey of the many ways trees can be used in UX: https://medium.com/@hagan.rivers/interaction-design-for-tree...

My favorite is the Tree Table

FWIW I am working on such a table library for React [0] which has a great tree plug-in. So you can use it either as tree table or tree list (if just having one column).

[0] https://react-table-library.com/

Did you see this collection? https://treevis.net/

Wow, that really is a great piece. Thanks for sharing.

Good efforts! Here's some quick feedback:

My first thought - how React Arborist is different from Ant Tree? https://ant.design/components/tree/

React Arborist dependencies looks sane https://github.com/brimdata/react-arborist/blob/main/package...

"memoize-one": "^6.0.0", "react-dnd": "^14.0.3", "react-dnd-html5-backend": "^14.0.1", "react-window": "^1.8.6"

However I was never a fan of react-dnd. Extremely hard to reason about react-dnd-html5-backend and spagetti code once you face edge scenarios.

Hard coded css means I need to fork the library

https://github.com/brimdata/react-arborist/blob/main/package...

  const style: CSSProperties = {
    position: "absolute",
    pointerEvents: "none",
    top: top - 2 + "px",
    left: treeView.indent + left + "px",
    right: treeView.indent + "px",
  };

Ant tree looks like a great tree library and is certainly more mature than react-arborist. However, react-arborist supports renaming a node, has a slightly different drag and drop feel, and leaves all styling up to the user. Not just the title, icon, and expand buttons.

I agree that the hard-coded DefaultCursor styles need to be configurable. I'll soon update. You'll be able to pass in your own component to render the DropCursor (blue line indicating the new position of the node you're dragging).

Been using AntTree with great success for a complex query builder. Highly recommend.

It looks very cool. However, I didn't see a license file, so I'm reluctant to try it out. Don't want to touch what I can't play with, that's what my momma always told me.

Oh sorry, it is MIT. I'll update the repo.

no need to apologize, I forget it all the time. Rather, I should thank you for making it MIT. Now I can use it if I want to create an electron app with react that can deal with the file system very good.

You're welcome. I created it for an electron app myself. I needed a sidebar like you see in VSCode.

Have you seen https://github.com/BlueMagnificent/monaco-tree?

Very sad to discover that this is NOT a ready made component to display actual trees. What a deceitful name!

Jokes apart, nice library. Will try it out sooner or later. May I suggest to not use children as the prop to Ps the Node component? Maybe a more explicit NodeComponent prop would have been better imho.

Dang it, I can see how the title was deceptive. This is headless component, leaving the markup and styling completely up to the user. Many of the tree components I looked at before building this didn't let me do exactly what I wanted with the style like this one does. However, I was thinking of shipping a default "<Item>" component that comes with some default styling to get people up and running quickly. I've just made an issue for this.

This is really great that it's headless btw, so many react components hard-code style that it's makes them difficult to use in another design system

I felt this same pain and it was one of main motivations to make this library.

If anything, it would be great to see some of the other components you’ve styled for this. The behavior is important but the visuals sell.

I think I would much prefer a documentation page going through styling the headless component vs ready made styled component with basic styles.

This is the approach used by most headless projects such has headless ui or radix.

> Very sad to discover that this is NOT a ready made component to display actual trees. What a deceitful name!

Hey, since you get to decide the structure yourself, I’m sure you could use that to draw a real tree using SVG.

There's a lack of performant, beautiful, extensible packages to visualize large JSON trees. It'd be nice to see a demo of that.

I totally agree. Firefox's default JSON viewer (an example[0] if u wanna try it with Firefox) is one of the most well-done tools I've come across at solving JSON trees. I wish I could get this as a component to play with in web design

[0] https://old.reddit.com/r/zerowaste.json

I tracked down the source of Firefox Devtools' JSON viewer.

https://github.com/mozilla/gecko-dev/tree/master/devtools/cl...

It's based on React, but also uses require.js for its dependencies from other parts of Devtools, like TreeView - so it looks tough to separate into an independent component.

I agree. If you want things to perform on the web, you've got to virtualize the rows. Many web libraries don't.

Great component, thank you for sharing. I was working on a similar component called `react-monaco-tree`, which is waay immature right now. I took `https://github.com/BlueMagnificent/monaco-tree` as the base. Are there any list of all these 'file-tree' components for React?

Looks like the start of a great component! It's amazing to me how there is not a really good tree component that already exists, considering how ubiquitous the tree is in user interfaces.

Yes you are right. I wouldn't start that component if I had seen react-arborist. Since then I am looking for good file tree components. Thank you for the contribution, I will keep looking for the alternatives but in the mean time react-arborist seems like a great choice.

Your company ( brimdata ) looks really good and your work on the Zed client app is impressive.

Thanks! We are prepping some blog content for after we get the next release out. You'll be seeing some more posts about zed on here soon.

Watched the talk linked on brimdata.io - stoked to see what's coming out. As a Typescript dev like yourself, very interested in how the dynamic types in Zed could be generated into ts, live.

… I like that it’s a controlled component.

I thought it was going to be a sortable tree-table like MacOS 8. I saw a tree like this in Java Applets in 1994.

Antd offers such a react component, as well as atlaskit

https://codesandbox.io/embed/9b6dxf?codemirror=1

https://atlassian.design/components/table-tree/examples

Yeah, this is not quite the tree-table component. Unless your table only needs one or two columns!

Does it miss Delete functionality for folders/files (I see rename) or I just dont see it?

This is a controlled component, so all mutation of the tree data structure will need to happen in the tree's parent component. Add a function in your node renderer (maybe after clicking a trash icon), that deletes the node from the tree state. The component will re-renderer and your node will be gone.

I was thinking of making a generic tree manager class to provide basic functions (move, rename, add, delete) for managing the tree data structure in the parent component. Maybe I'll call it "Arborist"!

Why provide the Node component as a child and not a prop? Seems less intuitive to me.

You can always set children in the component.

The library I used for virtualization does this. https://react-window.vercel.app I just followed Brian's pattern. I think it looks nice.

Reply on news.ycombinator.com