devongovett

9 ms·

31.
by devongovett 6y ago
Yep! ComboBox is also in progress/close. ;) https://github.com/adobe/react-spectrum/pull/421
32.
by devongovett 6y ago
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 sourc
33.
by devongovett 6y ago
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 s
34.
by devongovett 6y ago
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
35.
by devongovett 6y ago
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 de
36.
by devongovett 6y ago
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
37.
by devongovett 6y ago
Each component page has live examples. e.g. here's Button https://react-spectrum.adobe.com/react-spectrum/Button.html
38.
by devongovett 6y ago
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.
39.
by devongovett 6y ago
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, accessi
40.
by devongovett 7y ago
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
41.
by devongovett 7y ago
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 co
42.
by devongovett 7y ago
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 Par
43.
by devongovett 7y ago
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
44.
by devongovett 7y ago
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.
45.
by devongovett 7y ago
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 pro
46.
by devongovett 7y ago
Coming in Parcel 2! :) https://github.com/parcel-bundler/parcel/blob/v2/packages/co...
47.
by devongovett 7y ago
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.
48.
by devongovett 7y ago
Yep! I think we should be able to publish a JSON schema definition that editors like vscode can use to provide autocomplete etc.
49.
by devongovett 7y ago
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
50.
by devongovett 7y ago
Yep, we’re definitely going this direction with Parcel 2. :)
51.
by devongovett 7y ago
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
52.
by devongovett 7y ago
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
53.
by devongovett 7y ago
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. :)
54.
by devongovett 7y ago
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.
55.
by devongovett 7y ago
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
56.
by devongovett 7y ago
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. :)
57.
by devongovett 7y ago
Parcel works with normal .babelrc configs the same way as webpack or other tools. Curious what you couldn't change.
58.
by devongovett 8y ago
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! :)
59.
by devongovett 10y ago
For other browsers, you can use flac.js: http://github.com/audiocogs/flac.js .
60.
by devongovett 11y ago
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

More ›