How to use filterDOMProps?

[stevegreco]

This is more of a question regarding best practices and patterns. As we build out our internal design system, we have regularely referenced React Spectrum and react-aria-components source code. We have seen the usage of a utility filterDOMProps but there really is not much info on this. I am mainly curious what the best practices around this are, and what this utility accomplishes in a Typescript world.

My first impression is that it is filtering out props from within the component, so what role does this play if our users are using Typescript exclusively?

It seems to me that this utility is mostly a fallback to ensure that random props do not leak to the DOM in a Non-Typescript environment, would that be a good assumption?

It seems like filterDOMProps does not also include props like style and className, so would the idea be that those DOM props always get manually added to our types and de-structured out?

[snowystinger]

Thanks for the dicussion.

filterDOMProps is an undocumented internal utility we use to prevent random props from being spread on the dom nodes we render. It isn't intended for external use.

If you're just curious what it does, it allows through id first and foremost, then data-*, then possibly labelling props depending on how it is used. You shouldn't need to use it. If you're creating your own RAC compatible components, you can use your own filtering to accomplish what you need to avoid specific props ending up places they shouldn't.

Because it's undocumented and therefore considered private, we do not guarantee its API in semver. If there's a strong reason, we can discuss making it public.

[stevegreco]

Thanks for responding.

As a fellow Design System maintainer, I was mostly just curious about its usage for our internal Design System. We are heavily leveraging React Aria Components, but there are a few limited components, like Card that are basically just DOM elements that do not utilize RAC. We were looking for alternatives to using React.HTMLAttributes<HTMLDivElement> for something like that.

Our internal teams are largely leveraging Typescript, so I think for the most part we are probably covered. It seems like using the out of the box React types for those DOM nodes covers a lot of the bases. What do you see as the main value add for a filter like this?

[snowystinger]

It's mostly there to assist us in making sure pass the id and data-* attributes through to the dom node. You could also just pass id explicitly, and pull all the data-* attributes out and just spread those. This function just happens to do both of those at the same time and gives us a little handle to include aria-labels and link props as well.

Typescript is a good safeguard, but @ts-ignore or not using typescript would, without our filter, allow users to pass anything they wanted to our props and, therefore, to our rendered node. This might result in aria attributes that should not be present, or it could result in a React warning about unknown prop on dom element.

You don't need something like it to work with RAC. If you find yourself repeatedly pulling out certain props to pass along, then you may want to write something similar. I would not use our filterDOMProps function however, as I mentioned before, it's undocumented and therefore private.