-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use es6 class syntax #376
Use es6 class syntax #376
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really cool! ✨ I left a lot of comments but most of them are about bringing a bit of spacing around some code with empty lines. :)
const TAB_KEY = 'Tab' | ||
const ESCAPE_KEY = 'Escape' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also wondering whether we should just call these TAB
and ESCAPE
. This can be done separately though.
* @typedef { import ('./a11y-dialog').A11yDialog } A11yDialogType | ||
* @typedef { import('./a11y-dialog').EventType } EventType | ||
* @typedef { import('./a11y-dialog').EventHandler } EventHandler | ||
* @typedef { import('./a11y-dialog').ListenersRecord } ListenersRecord |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So what’s any of this? 😹
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Force of habit? 🤣 This is JSDoc syntax that imports the types defined in the d.ts file, so they can be referenced with the @param keyword. It’s not necessary since we know TypeScript is coming soon, though
|
||
return this | ||
} | ||
this.previouslyFocused = null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kind of liked to have a leading underscore for properties and methods that are not part of the public API. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it when we have no way in a language to indicate privacy to the dev, but we can use the keyword “private” in TypeScript, so I think I would prefer not to have leading underscores since we’re about to migrate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We’ll need to clarify the name change in the changelog though, since some people might be relying on these “hidden” properties.
// stays trapped within the dialog element | ||
if (this.shown && event.key === TAB_KEY) { | ||
trapTabKey(this.$el, event) | ||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/** | |
/** |
// This is an escape hatch in case there are nested dialogs, so the keypresses | ||
// are only reacted to for the most recent one | ||
if (!this.$el.contains(document.activeElement)) return | ||
// If the dialog is shown and the ESC key is pressed, prevent any further |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// If the dialog is shown and the ESC key is pressed, prevent any further | |
// If the dialog is shown and the ESC key is pressed, prevent any further |
event.preventDefault() | ||
this.hide(event) | ||
} | ||
// If the dialog is shown and the TAB key is pressed, make sure the focus |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// If the dialog is shown and the TAB key is pressed, make sure the focus | |
// If the dialog is shown and the TAB key is pressed, make sure the focus |
const minify = { | ||
plugins: [terser()], | ||
banner: () => `/*! a11y-dialog ${pkg.version} — © Kitty Giraudel */`, | ||
const babelCfg = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to spend a bit of time digesting this config. It’s been a while I haven’t played with Babel. :)
const minify = { | ||
plugins: [terser()], | ||
banner: () => `/*! a11y-dialog ${pkg.version} — © Kitty Giraudel */`, | ||
const babelCfg = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to spend a bit of time digesting this config. It’s been a while I haven’t played with Babel. :)
noClassCalls: true, | ||
noDocumentAll: true, | ||
}, | ||
presets: [['@babel/preset-env', { targets: 'ie 11' }]], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it really needed to transpile to IE11? As IE11 is out of support, when opening IE11 it suggets to download edge. @KittyGiraudel @mxmason
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, @tomasvn! IE 11 has reached its end-of-life, but it might also be the case that certain enterprises have an extended support agreement, and will still be using IE 11. I see two paths forward:
- Drop support for IE 11 in version 8 of a11y-dialog; direct IE users to version 7
- Continue support for IE 11 in version 8 of a11y-dialog, keeping the PR as-is
Ultimately, I think the right path forward should be @KittyGiraudel's decision.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be interesting to know the size difference with or without IE11 support in the ES5. If the difference is marginal, we should keep it because why not. If it’s significant, maybe we could drop it and refer people to v7.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Downleveling es6 to es5 makes the non-esm build about 0.2kb bigger than it used to be, and 0.3kb bigger than the ESM build that this branch produces.
ESM: 1.2kb (currently 1.3kb in prod)
UMD: 1.5kb (currently 1.3kb in prod)
I'm comfortable with shipping the additional kb to maintain support if you are. It's no real cost to our developer experience, as far as I can see it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, let’s keep IE11 support. That’s marginal if anything.
@mxmason How do you feel? Shall we merge it? :) |
@KittyGiraudel I'm good to merge this in if you are. I think I can move on to a TypeScript migration next, and then perhaps some small implementation changes, like the delegation you mentioned. |
Yaaaay! ✨ |
Summary