-
Notifications
You must be signed in to change notification settings - Fork 22
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
#2865: Various notification improvements #3531
Conversation
); | ||
|
||
function getMessageDisplayTime(message: string): number { | ||
const wpm = 100; // 180 is the average words read per minute, make it slower | ||
return Math.min( | ||
return Math.max( |
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.
Fix Notification timer (it was being ignored)
Fixed: All the notifications without a specified duration would last 2 seconds regardless of length
@@ -193,7 +193,6 @@ | |||
"@types/json-stringify-safe": "^5.0.0", | |||
"@types/lodash": "^4.14.171", | |||
"@types/mustache": "^4.1.2", | |||
"@types/notifyjs-browser": "0.0.0", |
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.
Drop outdated types (requires review)
I think that Notify.js’ types are somehow part of the public Alert brick’s config and the whole object was being passed as was to the notifier. However we kind of broke that months ago when we dropped the library. In practice I don’t think this was used for anything more than changing the className/type.
Now I'm making the last step of replacing the className
setting with just type
.
There's no migration path and I don't think it was ever necessary since error events should use error
type, and so on…
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.
Now I'm making the last step of replacing the className setting with just type.
It's probably fine, but I'd have to see if anyone (probably not) is using the following affordance in production: https://github.com/pixiebrix/pixiebrix-extension/pull/3531/files#r885082918
However we kind of broke that months ago when we dropped the library. In practice I don’t think this was used for anything more than changing the className/type.
Given your comment here, it sounds like if anyone was using it, we would have heard about it? If no one is, I will need to drop the support from menu item extension
What you're referring to is it that the old code destructured className? Or what exactly are you referring to?
{ message, config: { className } }: MessageConfig
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.
That's correct. When I changed library months ago I mapped the className
to the type
property because that's how our code was using the library.
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.
That's correct. When I changed library months ago I mapped the className to the type property because that's how our code was using the library.
Re-read some of our old documentation. With the old library you could pass props for controlling whether it was dismissible, etc. It wasn't very well documented and wasn't exposed in the Page Editor, though
<span> | ||
{message} | ||
<> | ||
<span className={styles.message}>{message}</span> |
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.
id, | ||
duration, | ||
// Keep the notification centered on the document even when the sidebar is open | ||
style: { marginLeft: `calc(var(${SIDEBAR_WIDTH_CSS_PROPERTY}, 0) * -1)` }, |
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.
config: Partial<NotificationOptions>; | ||
} | ||
|
||
export function notifyResult( |
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.
Dropped, showNotification
takes its place. extensionId
wasn't used and now it just matches that function
extension.id, | ||
merge({}, onSuccess, DEFAULT_ACTION_RESULTS.success) | ||
); | ||
showNotification({ ...DEFAULT_ACTION_RESULTS.success, ...onSuccess }); |
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.
@fregante changing the the API breaks this. This was an affordance for menu extension authors to customize the style/configuration of the notifications
I don't think anyone ever used the feature in production, but I'm going to have to double-check before merging in the PR
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 forgot to comment on this, but I think this never worked. Didn't the order of the parameters here guarantee that the user's message and className properties would always be overridden by the DEFAULT_* object?
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.
Didn't the order of the parameters here guarantee that the user's message and className properties would always be overridden by the DEFAULT_* object?
I think you're right. I probably had misread the lodash documentation and never tested it manually with the overrides
https://lodash.com/docs/4.17.15#merge Source objects are applied from left to right. Subsequent sources overwrite property assignments of previous sources.
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.
@fregante I need to double-check this before merging: #3531 (comment)
But had a question for you in that comment
Codecov Report
@@ Coverage Diff @@
## main #3531 +/- ##
=======================================
Coverage 40.44% 40.44%
=======================================
Files 772 772
Lines 22474 22478 +4
Branches 4722 4725 +3
=======================================
+ Hits 9089 9091 +2
- Misses 12465 12467 +2
Partials 920 920
Continue to review full report at Codecov.
|
The remaining 3 points will have to wait and/or be followed by someone else (they depend on the library or need some React setup)
You can find the details of these changes in the review that follows.