Video wird geladen...

Video konnte nicht geladen werden

Zur Startseite

Why does React Aria have its own Virtualizer? Why not use an existing library? Accessibility. If you combine a virtualizer with most component libraries, you might notice that keyboard navigation breaks. That's because scrolling the focused element out of view removes it from the DOM. Then when you press...

20,397 Aufrufe • vor 1 Jahr •via X (Twitter)

10 Kommentare

Profilbild von Devon Govett
Devon Govettvor 1 Jahr

We also automatically add ARIA attributes like aria-setsize and aria-posinset to items so that screen readers know where they are in the entire list, rather than only what's in the DOM. Hierarchy is also important. If you have a list with sections, keeping the headers in the DOM when items within a section are visible preserves the ability for screen readers to announce properly. We also integrate with React Aria's drag and drop, table column resizing, etc.

Profilbild von Devon Govett
Devon Govettvor 1 Jahr

But, like all of React Aria Components, there's always a lower level API if you want to do something custom. Virtualizer is built on our CollectionRenderer API, which lets you customize how collection components are rendered to the DOM. So you could use this to integrate with a different virtualizer library. Just keep those accessibility features in mind! 🙂

Profilbild von Alex Vipond
Alex Vipondvor 1 Jahr

Persisting the focused element is genius 🧠

Profilbild von Andy Hook
Andy Hookvor 1 Jahr

Great work Devon + team

Profilbild von Gijs Rogé
Gijs Rogévor 1 Jahr

Does that mean ctrl+f keeps working?

Profilbild von Devon Govett
Devon Govettvor 1 Jahr

I don't believe there is a way to do that without rendering all items to the DOM, which defeats the performance benefits of virtualizing. We'd need a new browser API I think.

Profilbild von Unbound
Unboundvor 1 Jahr

Have you considered improving accessibility in an existing open source project? Is it really harder than making the whole library from scratch?

Profilbild von Devon Govett
Devon Govettvor 1 Jahr

Actually, we've been using this implementation in production for almost 10 years now! It's been open source for almost 5, as part of React Spectrum. Really, this is just integrating it with React Aria Components and adding docs.

Profilbild von Saurabh 🔅🦀
Saurabh 🔅🦀vor 1 Jahr

Does this work well with a large draggable list tree? Most of them do not work with a draggable context.

Profilbild von Devon Govett
Devon Govettvor 1 Jahr

Yes drag and drop is integrated.

Ähnliche Videos

Hell froze over: announcing FormKit for React. Secretly framework-agnostic since inception, today we’re open sourcing the most popular Vue form library…for React. Why is this a big deal? 1. Forms are still hard. We (the creators of FormKit) thought form libraries were no longer necessary, given the trajectory of coding agents. It turns out we were wrong, and we learned this the hard way. Need repeating conditional fields nested 3 layers deep inside a dynamic component, with accessibility, validation, internationalization, and backend error placement? Turns out coding agents aren’t great at that. It’s table stakes for FormKit. 2. Single component. This matters more than you would think, but FormKit doesn’t ship lots of different components each with its own props. Instead, it has a single one: and unified props. This was done to provide a better DX to human engineers. It makes it easy to spot when a given component was part of the form’s data structure vs a presentational component. It turns out this matters even more to coding agents than humans. No matter where your coding agent is, whenever it sees “FormKit” it immediately knows “oh, that’s part of the form’s data”. 3. No plumbing. FormKit doesn’t require any manual data collection, event listening, or state tracking. It does all this for you on a heavily tested, framework agnostic, self-assembling graph. The only code your agent needs to write is declarative templates and submission handlers that respond to the state. 4. Dense colocation. FormKit’s syntax happens to be ideal for coding agents; nearly everything you need to know about a given input is *on* the input: Colocation dramatically improves the efficacy of coding agents. 5. DOM. FormKit, unlike most form frameworks in React, renders the actual DOM. This also increases colocation and best practices, meaning your coding agent is far more likely to produce consistent and high-quality output that looks and acts the way its supposed to. 6. Schema. FormKit’s own inputs are not written using Vue or React — instead, FormKit has its own render schema — think of it like an AST for the DOM — and you can modify it on the fly. It’s not very human-friendly to write, but it turns out most models are already pretty well trained on FormKit’s schema. Want your inputs to look a bit different on one form than another? No problem, your coding agent can easily make those changes *without* modifying the JSX structure at all. Oh, and any inputs you create for Vue work with React and vice versa. 7. Plugins. FormKit leans into the unstructured tree graph hard. The graph doesn’t just collect data, it also passes down configuration and plugins. Want one form to work a bit differently than another one? No problem — just add a plugin to the top of that form or group and its children will all receive that feature. You can even mass assign props and configuration this way. Of course, FormKit has been solving these exact issues for a long time, but it wasn’t until we started using it on our own projects with coding agents that we realized what a huge advantage it is. With so many people using coding agents with React, it made sense to unveil FormKit for what it has always been — a completely framework-agnostic form framework that happens to unlock your coding agents. ➡️

Justin Schroeder

11,549 Aufrufe • vor 2 Monaten