Skip to content
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

Merged
merged 14 commits into from
Jul 7, 2022
Merged

Conversation

mxmason
Copy link
Contributor

@mxmason mxmason commented Jul 1, 2022

Summary

  1. Refactors the source file to use ES6 class syntax
  2. Updates the typedef file accordingly
  3. Refactors the rollup config

@mxmason mxmason marked this pull request as ready for review July 1, 2022 17:35
Copy link
Owner

@KittyGiraudel KittyGiraudel left a 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. :)

Comment on lines +3 to +4
const TAB_KEY = 'Tab'
const ESCAPE_KEY = 'Escape'
Copy link
Owner

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.

Comment on lines +7 to +10
* @typedef { import ('./a11y-dialog').A11yDialog } A11yDialogType
* @typedef { import('./a11y-dialog').EventType } EventType
* @typedef { import('./a11y-dialog').EventHandler } EventHandler
* @typedef { import('./a11y-dialog').ListenersRecord } ListenersRecord
Copy link
Owner

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? 😹

Copy link
Contributor Author

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

src/a11y-dialog.js Show resolved Hide resolved

return this
}
this.previouslyFocused = null
Copy link
Owner

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?

Copy link
Contributor Author

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.

Copy link
Owner

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.

src/a11y-dialog.js Outdated Show resolved Hide resolved
// stays trapped within the dialog element
if (this.shown && event.key === TAB_KEY) {
trapTabKey(this.$el, event)
/**
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/**
/**

// 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
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// 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
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// 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 = {
Copy link
Owner

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 = {
Copy link
Owner

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' }]],
Copy link
Contributor

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

Copy link
Contributor Author

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:

  1. Drop support for IE 11 in version 8 of a11y-dialog; direct IE users to version 7
  2. 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.

Copy link
Owner

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.

Copy link
Contributor Author

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.

Copy link
Owner

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.

@KittyGiraudel
Copy link
Owner

@mxmason How do you feel? Shall we merge it? :)

@mxmason
Copy link
Contributor Author

mxmason commented Jul 7, 2022

@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.

@KittyGiraudel KittyGiraudel merged commit 30dd29a into KittyGiraudel:main Jul 7, 2022
@KittyGiraudel
Copy link
Owner

Yaaaay! ✨

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants