-
Notifications
You must be signed in to change notification settings - Fork 77
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
Add notification bar component. (Fixes #383) #431
Add notification bar component. (Fixes #383) #431
Conversation
Should we support a standard set cookie for components that utilize a dismiss function like this in protocol? I'm not sure if this should be baked in on a per-component basis or a reusable token(?) of some kind. |
My personal take here is that Protocol shouldn’t use or require setting any form of cookies in its code (that’s probably a bigger discussion that we’ve yet to have). Providing a callback when the notification is dismissed should be enough so that consumers (i.e bedrock) can then use cookies if required. It can also be useful for things like GA, which can differ from site to site. It might be nice to have a JavaScript API that enables showing the notification itself too, vs a script that does it automatically on load? Also, tests! |
d10e531
to
dccb251
Compare
dccb251
to
c90dc5a
Compare
A few drive-by opinions, not a review because I know it's WIP. It probably shouldn't be an We should move the close button to the left in RTL. And this is more of a discussion for the designers, but I'm not sure the "click" variant should even exist. It appears in the brand guide but I think it was just an example of "use blue for actions," it wasn't a fully thought-through component. If there's an action to be taken it shouldn't take the form of a big pseudo-button with its own little dismiss button inside it. We should get some more opinions on that. I also think we might need a neutral notification for messages that aren't warnings, errors, or successes, just general notices. Maybe with a light gray background, or white with a blue or purple border? |
@stephaniehobson If you have a moment tomorrow, would you mind taking a look at this? I've refactored the JS a bit but I'm struggling with the unit test portion (or perhaps the JS needs to be refactored more?) 😔 |
@alexgibson would you mind taking a look at this tomorrow? (only if you have the time, is not a p1) |
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 took a look at the tests and left a few comment / suggestions.
Happy to review this more fully when you think it's ready. Looking great!
@alexgibson thanks for the feedback, Alex! I tidied things up and everything seems to be working as it should. I only have two unit tests for opening & closing a notification, I wasn't sure what else to include? |
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.
A few comments / suggestions, and might need a small refactor to work on the browsers bedrock needs to support. But overall I think this is looking teriffic, nice work!
I think the way you've written it feels right, but we should also consider that on some pages we may not require the use of JavaScript at all. For example, this bar is already on /firefox/download/thanks/ (minus the close button). As long as we have the option to include it statically on pages without needing JavaScript, then what you're added here is a nice progressive enhancement, should we ever need it 👍 |
010562b
to
093b6ab
Compare
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.
Took a second pass, looking good! The styles for small screens (i.e. mobile) could use a few tweaks, but the content is resizing well for all other breakpoints 👍
// add title to notification | ||
notification.appendChild(notificationTitle); | ||
}else{ | ||
console.log('Notification banner requires title parameter.'); // eslint-disable-line no-console |
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 don't think we should leave console.log()
in as production code, since it can cause errors in older browsers unless dev tools are open.
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.
agreed! will fix that up tomorrow.
One other thought: we should consider a11y when a notification is programatically opened using JS. What should happen: should focus move to the notification title when it is displayed? Should that be required, or optional? Do we need any additional ARIA information? |
Tests are passing locally, I'm not sure why travis is failing. Also, I'm not entirely sure what additional ARIA information may be useful here. @alexgibson |
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.
One suggested change on why the tests are failing, but otherwise looks great.
I'd suggest we file separate issues for followups on this component:
- Improve a11y when a notification opens.
- Allow a notification to contain a link (such as the one on /download/thanks/)
Does that sound about right?
expect(notification).toBeTruthy(); | ||
}); | ||
|
||
it('closes as expected', function() { |
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.
Here you've created an ordered dependency on the "open" test needing to run before the "close" test, which will lead to intermittent failures. Tests run in a random order and not sequentially (hence why this passes sometimes and not at other times, like in CI).
I'd suggest treating each test as it's own distinct piece of logic. Before each test runs you should create the notification, and after each test finishes you should remove the notification. That way, tests should pass regardless of the order they are run.
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.
One last suggestion on tidying up after the tests, but it's a nit. This looks great, nice work!
|
||
'use strict'; | ||
|
||
beforeEach(function () { |
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.
Nit: Suggest adding an afterEach
below here to remove the button after each test also?
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.
Ah! Yes! Good catch!
Description
Adds the notification bar component used on /thanks and /whatsnew
CHANGELOG.md
.Issue
#383
mozilla/bedrock#7468
Testing
https://demo2--mozilla-protocol.netlify.com/patterns/molecules/notification-bar.html
Supports different styles:
Dismiss is optional.