-
Notifications
You must be signed in to change notification settings - Fork 5
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 object (key is type safe) to choice alert message rather than switch #479
Conversation
src/session/Timer.tsx
Outdated
const alertMessageByNotificationPermission: { | ||
[key in NotificationPermission]: string; | ||
} = { | ||
granted: "Thanks to accept the notification :)", | ||
denied: "You rejected the notification :(Please accept it.", | ||
default: "Can not judge to use notification :(Please accept 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.
const alertMessageByNotificationPermission: { | |
[key in NotificationPermission]: string; | |
} = { | |
granted: "Thanks to accept the notification :)", | |
denied: "You rejected the notification :(Please accept it.", | |
default: "Can not judge to use notification :(Please accept it.", | |
}; | |
const alertMessageByNotificationPermission = { | |
granted: "Thanks to accept the notification :)", | |
denied: "You rejected the notification :(Please accept it.", | |
default: "Can not judge to use notification :(Please accept it.", | |
} as const; |
is simple and robust here, dependent NotificationPermission is enough in fetching key, I think
And I suggest to put this object out of this Timer function, this does not depends any context and variables.
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 got another idea now. How about this?
if (window.Notification && Notification.permission !== "granted") {
Notification.requestPermission((result) => {
const alertMessageByNotificationPermission: {
[key in typeof result]: string;
} = {
granted: "Thanks to accept the notification :)",
denied: "You rejected the notification :(Please accept it.",
default: "Can not judge to use notification :(Please accept it.",
};
alert(alertMessageByNotificationPermission[result]);
});
}
My thought of key in ~
's advantages are:
- Using
as const
doesn't prevent adding "extra" elements. key in ~
can get good IDE support.
On the other hand, I agree using as const
is more simpler.
I'd like to hear your opinion again which is better.
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 can understand your motivation to write key ~.
I have 2 suggestions as below
Notification.requestPermission((result) => {
alert(
{
granted: "Thanks to accept the notification :)",
denied: "You rejected the notification :(Please accept it.",
default: "Can not judge to use notification :(Please accept it.",
}[result]
);
});
This is simple and typescript supports the branches, my favor.
The constant only use here, less cost, so writing as literal is best, I think.
However if you want to extract to another variable, as const
makes readonly, I prefer the benefit.
const alertMessageByNotificationPermission: { | |
[key in NotificationPermission]: string; | |
} = { | |
granted: "Thanks to accept the notification :)", | |
denied: "You rejected the notification :(Please accept it.", | |
default: "Can not judge to use notification :(Please accept it.", | |
}; | |
const alertMessageByNotificationPermission: Readonly<{ | |
[key in NotificationPermission]: string; | |
}> = { | |
granted: "Thanks to accept the notification :)", | |
denied: "You rejected the notification :(Please accept it.", | |
default: "Can not judge to use notification :(Please accept it.", | |
}; |
This is a similar way as 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.
I like it! Let me update.
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.
addressed in 2e302af
Cloud you check again?
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 would update this with #724
HashMap based state transition is one of my favor too. I agree to use this way here 👍 (BTW, in TypeScript layer, it has same meanings. However thinking in JavaScript, it might be different for making error possibilities 😇 ) |
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.
LGTM 👍
…#724) * Prefer `as const` with TypeScript 4.9 introduced `satisfies` operator microsoft/TypeScript#47920 https://devblogs.microsoft.com/typescript/announcing-typescript-4-9-rc/#satisfies This is my hope since #479 (comment) * `npm run build` To includes babel 7.2.0 https://babeljs.io/blog/2022/10/27/7.20.0 * `npm i -g npm-check-updates && ncu -u` To bump jest to apply jestjs/jest#13199 (comment) * `npm install` * Revert "`npm i -g npm-check-updates && ncu -u`" This reverts commit 1131421. * Revert "`npm install`" This reverts commit 2dfc43e. * Specify TS 4.9 satisfies supported babel plugin with npm overrides https://babeljs.io/blog/2022/10/27/7.20.0 https://docs.npmjs.com/cli/v8/configuring-npm/package-json#overrides vitejs/vite#7634 #724 (comment)
How about to use object (hash map) to choice alert message?
I think this is same with using switch statement from the perspective of type safety.