1. We decided to start simple for the first release but it’s definitely possible to add something like asChild if the need arises. There are some tradeoffs to this though, eg it’s easier to mess up the DOM structure required for accessibility. There are some other approaches we’ll be documenting for this as well.
2. TS should be easier now. All the docs examples are now written in TS so you can see where the interfaces are imported from.
3. Yeah prop naming is a trade off. When we started, we decided to make all of the components follow a consistent naming convention. The DOM is quite limited in its functionality (eg you can only submit strings and not more complex objects) and we knew we’d need quite a bit more capability so we decided not to follow it in some areas. But we know integrating with form libraries is a pain point and we might have some documentation or helpers for that in the future.
If you have a trigger inside a nested scrollable region, and the popover pops out of this region, then if the trigger is scrolled out of view the popover cannot be anchored to it anymore.
This was an intentional choice. Repositioning when an outer element scrolls is pretty janky in some cases because scroll events don’t fire at 60fps. Also it’s not possible at all in other cases, like if the trigger goes completely out of view. We used to close the popover in this case but this caused usability problems. The new behavior of preventing scroll actually matches native platforms like macOS and helps with these issues. I get that it’s a little opinionated but it was thoroughly considered, not just done out of laziness. More details in this answer: https://github.com/adobe/react-spectrum/discussions/3802#dis...
I have been thinking about implementing the CSS OM spec as the JS API. This is the same API that browsers expose for manipulating stylesheets. The advantage of this is that we don't need to invent something custom. Still thinking through options. https://github.com/parcel-bundler/parcel-css/issues/5
That said, I think I'd want to keep the use cases for JS plugins limited, because it will affect performance significantly. So, if it's something that exists in an official CSS spec somewhere (even if draft), or a really common transformation, it should be implemented in Rust. An example of this is the support for the CSS nesting spec. Ideally, we'd try to keep the amount of custom syntax being invented around CSS to a minimum and stick to standard CSS syntax wherever possible though.
I work on React Aria. Adobe is a big company and there are many teams using different technologies. In general, some very new parts of creative cloud chose to use web components, but the majority of teams are using React, and I don't foresee that changing anytime soon. It's definitely not a company wide shift if you got that impression from the Photoshop article. Ideally we'd collaborate more, but... big company silos.
I commented elsewhere in this thread but that benchmark is really measuring the performance of Terser, which is used by all of the other tools listed there. Parcel has improved somewhat since that benchmark was last updated but until terser is replaced there’s no competition.
Parcel 2 does both: it is useful out of the box, and many projects will never need to configure it, but v2 adds a complete plugin system that lets you override and configure everything too. :)
1. We decided to start simple for the first release but it’s definitely possible to add something like asChild if the need arises. There are some tradeoffs to this though, eg it’s easier to mess up the DOM structure required for accessibility. There are some other approaches we’ll be documenting for this as well.
2. TS should be easier now. All the docs examples are now written in TS so you can see where the interfaces are imported from.
3. Yeah prop naming is a trade off. When we started, we decided to make all of the components follow a consistent naming convention. The DOM is quite limited in its functionality (eg you can only submit strings and not more complex objects) and we knew we’d need quite a bit more capability so we decided not to follow it in some areas. But we know integrating with form libraries is a pain point and we might have some documentation or helpers for that in the future.