devongovett

Yep! ComboBox is also in progress/close. ;) https://github.com/adobe/react-spectrum/pull/421

Many of our products also support third party extensibility, so the main business reason we pitched internally was making this easier for external developers. This helped us convince the bosses to invest in the project and let us open source and maintain it. And hopefully with React Aria, we provide value beyond the standard "look at our fancy components".

Adobe actually has a pretty big marketing business as well, along with applications like file managers (think web based versions of Finder or Windows Explorer). Tables are one of our most complex components, and are quite commonly used in some of our products. Our table implementation is a work in progress right now. It supports keyboard navigation, sections, sticky columns, multiple selection, infinite loading, drag and drop, etc. Should be available in a month or so. We'll also support other collections like trees/grids/column views in the future, and possibly some charting stuff as well. Lots still left to build! :)

1. Depends on how many components you use! Each component is a separate package, so you pay for only what you use. We also offer a monopackage containing all components, but it is fully tree shakeable so it should be equivalent to using the individual packages if you have a good build setup.

2. We're working on building some example apps, but for now, the docs are the best example. You can also try out the storybook that we use for development if you clone the repo locally.

I think it's more likely that people will want to use the React Aria and React Stately libraries that underpin this than React Spectrum itself, unless you're wanting to match the Adobe look and feel for some reason (e.g. plugin developers). React Aria and React Stately provide Hooks that give you a lot of the behavior, accessibility, internationalization, etc. features out of the box, but let you completely customize the styling and rendering in your own components. Here's an example I made of using the hooks with Tailwind CSS to build completely custom components with full accessibility in a very small amount of code: https://codesandbox.io/s/tailwind-react-aria-3ngmw.

No, moment is not a dependency. We're using the native Intl.DateTimeFormat APIs that are built into browsers now. This makes sure we support internationalization properly, but without the giant locale data needing to be downloaded.

And yes, we have a DateRangePicker and TimePicker as well.

Each component page has live examples. e.g. here's Button https://react-spectrum.adobe.com/react-spectrum/Button.html

Our date picker is in progress right now actually. Should be available relatively soon. Date pickers are one of the most complicated components, especially due to internationalization/accessibility requirements.

hey everyone. I work on React Spectrum. Happy to answer any questions. :)

I'd also point to our introductory post where we discuss the architecture. I think the most interesting thing is that you can reuse most of the behavior, accessibility, etc. without our design in your own component library using our hooks. https://react-spectrum.adobe.com/blog/introducing-react-spec...

Originally that's how it happened: I was working on a product and frustrated with build perf, so built parcel in my spare time to scratch that itch. Eventually convinced the team to adopt it.

Atlassian has 2 full time engineers working on Parcel now though, so they've made a pretty big investment.

We use json5, which allows comments.

You cannot statically cache the results of a .js file - it might include objects or functions that cannot be serialized, and might cause side effects that parcel cannot know about. If we supported .js config files, we would have to intentionally limit what you can return to basically just JSON, so you wouldn’t get much benefit from it and it would be hard to enforce.

Zero config doesn’t mean non-configurable. You still configure other tools that Parcel runs like Babel, TypeScript, etc. It’s not like create-React-app where if you want to customize anything you cannot (without ejecting). I like to say Parcel has config inference from your actual code, rather than making you declare every minute detail up front. But when you need to change something you can. I wouldn’t call that “opinionated”.

JSON is much more static and predictable for configuration. Config through a real programming language was a mistake that many tools made unfortunately. Static configuration has several nice properties including cacheability and simplicity that cannot be guaranteed in a full programming language. Just look at webpack.config.js for an example of the opposite.

Yep, we’ll definitely use a tool like that. We already have types in Flow for all of Parcel 2, so should be possible to do something similar.

This is somewhat true. I was working at Adobe while building Parcel in my spare time at first, mostly to improve build perf of an app at work. After it launched and we used it internally for a while, Adobe finally started sponsoring the project.

Now, Parcel 2 has a core team of 9 active members from various companies including Adobe, Atlassian, and Eventbrite. We also receive funding on Open Collective which we distribute to a couple independent members of the team who aren’t already sponsored by a company. Definitely a multi-company effort at this point! :)

Coming in Parcel 2! :) https://github.com/parcel-bundler/parcel/blob/v2/packages/co...

Is there another way to provide strong types for a JSON file?

I believe vscode uses schemas from http://schemastore.org/ for many config files already.

Yep! I think we should be able to publish a JSON schema definition that editors like vscode can use to provide autocomplete etc.

We’ve actually rewritten our watcher for Parcel 2 as a cross platform C++ module and it should be much more efficient. :) http://github.com/parcel-bundler/watcher

Yep, we’re definitely going this direction with Parcel 2. :)

We’ve tried very hard to avoid Parcel specific features actually. When we transform, we use other tools that the user has enabled, eg babel. An application that you build with Parcel does not produce Parcel specific output and there are as of yet no Parcel specific language features. It should be possible to switch to another build tool without much if any work. Definitely not the case with other tools like webpack though, so I can see where this comes from.

You’re right, this is happening to some degree with Parcel. Our aim with Parcel 2 is to open up the plugin system to allow more extensibility while keeping it as simple as possible to use out of the box. This is accomplished through a very well defined plugin system with explicit extension points for each step of the build pipeline (not the Wild West of extensibility like other tools), and a good default configuration that you can extend or override as needed with a simple JSON config format. The result is that you get everything Parcel 1 could do and more out of the box, but you can easily change or extend Parcel 2 with more features specific to your app if you need to.

We’ve been working on Parcel 2 for almost 2 years now (~1 year in design, another in development) and I think it strikes a pretty good balance. I’m excited to see what the community does with it! :)

Hehe. There's always been some confusion about the term "zero configuration". To us, it's always meant no config needed to get started (and for the 90% case), but possible to configure later if needed. :)

Parcel 2 should help with this a lot. It has a much improved plugin system that allows pretty much everything to be extended and overridden, while still keeping things easy to use by default.

We do include a lot more features out of the box than other tools, so this makes sense to some degree. In Parcel 2, we're splitting up the core into lots of small plugin packages so you can only install what you need. The Parcel 2 core is tiny - only a handful of dependencies.

We have support for outputting native ES modules in Parcel 2, which is currently in alpha! We can even compile your app to multiple targets to support modern/legacy browsers. :)

Parcel works with normal .babelrc configs the same way as webpack or other tools. Curious what you couldn't change.

I’m the creator of Parcel. This post is not accurate. Ryan does not represent webpack and there are no hard feelings between the teams. Please delete this post. Thanks! :)

For other browsers, you can use flac.js: http://github.com/audiocogs/flac.js.

Indeed. Contenteditable is awful, especially when collaboration is involved, since different browsers produce different HTML. I wrote a similar rich text editor for the Storify editor when we introduced real time collaboration, about a year ago. We intercept all of the editing events, perform whatever actions are necessary on our internal document format, and then manually sync those changes into the DOM. Our document format is designed in a way that can be synchronized in real time using operational transformation, which is impossible to do with HTML. This is really the only way to build a good rich text editor IMO.

I'm glad Prosemirror was written, since it sounds like it does similar things. Wish it existed a year ago. ;-)