devongovett
Joined 17 years ago
Karma
2,126
Submissions
248
Member since
Oct 8
Recent submissions
Comment · 3 years ago
Comment · 3 years ago
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.
Comment · 3 years ago
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...
Comment · 4 years ago
In Parcel 2, you can configure everything.
Comment · 4 years ago
Parcel 2 solved this though. You can override pretty much everything if you want now.
Comment · 4 years ago
We actually already have! I contributed hwb() color support as part of my work on Parcel CSS, and it shipped in Firefox 96! https://github.com/servo/rust-cssparser/commit/62d63fea751df...
Comment · 4 years ago
Yes, there is a WASM build used by the demo: https://parcel-css.vercel.app
Not sure if we could reuse these packages though, since we'd need to expose an API from Rust to JS anyway.
Comment · 4 years ago
Hi, author of Parcel CSS here.
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.
Comment · 5 years ago
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.
Comment · 5 years ago
Haha yes it is. We have to do a ton of manual testing to ensure consistency and compatibility across many devices, browsers, and screen readers.
Some of my tweets showing how we do this:
- https://twitter.com/devongovett/status/1318600389462126592 - https://twitter.com/devongovett/status/1270410802395111424 - https://twitter.com/devongovett/status/1318676759080968193
Comment · 5 years ago
Yeah ComboBox is one of the most difficult. We wrote a post about the work that went into ours. https://react-spectrum.adobe.com/blog/building-a-combobox.ht...
Comment · 5 years ago
If you want a bundler built using SWC as a base today, check out Parcel: https://parceljs.org
Comment · 5 years ago
And Parcel: https://parceljs.org
Comment · 5 years ago
Next.js still uses webpack. They basically replaced Babel with SWC.
Comment · 5 years ago
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.
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.