Unified Review Banner Base Shell
Review Request #10196 — Created Oct. 4, 2018 and discarded
The Unified Review Banner Base Shell sets the foundation for the Unified
Review Banner, which will eventually take over for the three banners
currently used for draft review requests, reviews, and review replies.The banner tracks the draft state of review requests, reviews, and
review replies so it can be put into a draft mode where the banner
appears green when at least one draft exists. The banner makes use of
RB.FloatingBannerView
to allow the banner to float to the top of the
screen when the user scrolls down. The newRB.Registry
model allows
views like dropdowns, buttons, and Backbone views to be registered in
different locations on the banner. There are placeholders registered to
the different banner sections right now which will later be removed or
replaced when the functionality of the Unified Review Banner is fleshed
out further.Currently, the Unified Review Banner is only shown when the Unified
Banner feature flag is enabled, by appending the following code to
settings_local.py
:ENABLED_FEATURES = { 'reviews.unified_banner': True }
Added new JS tests to test functionality added. All JS tests pass.
Manual test cases:
1. Review request draft by modifying description, testing done,
information -> banner should turn green
2. Review request draft by adding a file (through drag-and-drop and
Update > Add File) -> banner should turn green
3. Discard review request draft with button on unified banner -> banner
should turn brown, review request discarded
4. New review by adding comment in diff viewer -> banner should turn
green
5. Discard review with button on unified banner -> banner should turn
brown, review discarded
6. New review with header, general comment in review dialog -> banner
should turn green
7. Discard review in review dialog -> banner should turn brown, review
discarded
8. Review reply draft by adding review replies on one review -> banner
should turn green
9. Remove all text of review reply draft (empty string) -> review reply
should be removed, banner should turn brown
10. Review reply draft by adding review replies on multiple/all reviews
-> banner should turn green
11. Discard review reply drafts with button on unified banner -> banner
should turn brown, all review replies discarded
12. New review/review request and review replies added -> banner should
turn green
13. Discard with button on unified banner -> banner should turn brown,
review and review replies discarded*reload case (where on reload the correct banner state persists) tested
on all non-discard test cases
Description | From | Last Updated |
---|---|---|
Can you add screenshots? |
brennie | |
To set the feature flag, I think you meant appending the code to settings.py |
bolariinwa | |
You only need & if you want to specialize the parent selector e.g.: .foo { &.bar { // Equivalent to … |
brennie | |
You only need _.defaults when combining objects. This can just be: defaults: { hasDraft: false, }, |
brennie | |
Nit: space between if and ( |
brennie | |
We only need the [].join('') in ES5 because it does not have multiline strings. You can just do: javascript: template: … |
brennie | |
ES6 lets us do render(). Same below. |
brennie | |
This is going to run when the file is sourced, and so this object might not exist? We may want … |
brennie | |
this is undefined here. The second object passed to Backbone.{...}.extend is applied directly to the created object instead of its … |
brennie | |
Col: 15 'pendingReview' is defined but never used. |
reviewbot | |
Hey Sarah, Great work so far! I just wanted to clarify, I know that var is bound to the execution … |
Sudolicious | |
Same thing as above, do these need to be declared with var? |
Sudolicious | |
I'm only asking cause I thought we should avoid var entirely. |
Sudolicious | |
I think this description is a bit of a mouthful. Would something like this be a more sufficient summary? "A … |
Sudolicious | |
Hey Sarah! Is this TODO for you to work on in your project, or is this for somebody in the … |
skaefer143 | |
Hey Sarah! Is this TODO for you to work on in your project, or is this for somebody in the … |
skaefer143 | |
This comment should be a full sentence, with a period. |
skaefer143 | |
This comment should be a full sentence, with a period. |
skaefer143 | |
This comment should be a full sentence, with a period. |
skaefer143 | |
You can use an arrow function here in order to avoid assigning const that = this; Since arrow functions don't … |
Sudolicious | |
This should be // TODO: Full sentence.. Though I don't know that this is necessary. |
brennie | |
Same here. |
brennie | |
This should probably be #unified-banner-docked. Same for other selectors: they should spell out the entire phrase. |
brennie | |
Should be organized like: .selector { property: value; &-selectors {} .other-selectors {} } |
brennie | |
.selector * is super expensive. CSS selectors are applied right-to-left, so the * will match every DOM element and then … |
brennie | |
.selector * is super expensive. See other comment. |
brennie | |
This needs a corresponding afterEach() to reset the feature to its original value. |
brennie | |
Doc comments should be of the form: /** * Single line summary. * * Multi-line description. */ |
brennie | |
Since reviewReplyDrafts is an Array, which is mutable, this needs to be a function: defaults() { return { hasDraft: false, … |
brennie | |
Missing doc comment. |
brennie | |
Why these? These are in the defaults. |
brennie | |
The arrow function should be aligned with the first argument. The arrow functino should be () => this._updateHasDraft(). Making it … |
brennie | |
Again, this should just be hasDraft. Also, we can rewrite this using Backbone.Model.prototype.isNew(). const hasDraft = (!this.get('reviewRequest').isNew() || !this.get('pendingReview').isNew() || … |
brennie | |
We are declaring a variable and then immediately using it once. We should move it inline. |
brennie | |
Doc comments should be of the format: /** * Single line summary. * * Multi-line description. */ |
brennie | |
These arrow functions can be a single line. |
brennie | |
Missing a summary. |
brennie | |
We don't do local vars with leading underscores. |
brennie | |
You are re-using this in closures. Is this intentional? |
brennie | |
This should be formatted as either: this.listenTo(reviewReply, 'saved', () => { // ... }); // or this.listenTo( reviewReply, 'saved', () … |
brennie | |
Blank line between these. |
brennie | |
Instead of _.findWhere, why not: if (!_reviewReplyDrafts.includes(reviewReply)) _.findWhere compares all attributes instead of just comparing for equality. Two models with … |
brennie | |
This can be rewritten as: this.listenTo( reviewReply, 'destroying', () => this.set('reviewReplyDrafts', _.reject( this.get('reviewReplyDrafts'), draft => draft.id === reviewReply.id))); |
brennie | |
Any reason you're not using arrow syntax? |
brennie | |
This should be formatted as: this.listenTo(reviewReply, 'destroyed', () => this._updateHasDraft()); The { and } are unnecessary for a single-line lambda. |
brennie | |
Blank line between these. |
brennie | |
Same here re: findWhere |
brennie | |
Doc comments should be of the format: /** * Single line summary. * * Multi-line description. */ |
brennie | |
Blank line between these. |
brennie | |
Undo this formatting change. |
brennie | |
There should be a corresponding afterEach() that resets RB.EnabledFeatures.unifiedBanner. |
brennie | |
There should be a corresponding afterEach() that resets RB.EnabledFeatures.unifiedBanner. |
brennie | |
This is unnecessary. |
brennie | |
This should be a full sentence. |
brennie | |
"Attributes" should be capitalized here. |
david | |
Since this is implemented as a method, it should have a doc comment. |
david | |
This can be cleaned up a bit: _.bindAll(this, '_updateHasDraft'); this.listenTo(reviewRequest.draft, 'saved destroy', this._updateHasDraft); this.listenTo(pendingreview, 'saved destroy', this._updateHasDraft); |
david | |
Instead of !!, can we just compare > 0? |
david | |
If you do the bindAll in initialize, you can just pass in ready: this._updateHasDraft, here. |
david | |
I think it would be better to have multiple const reviewReplyDrafts = ... in each place that it's used. Right … |
david | |
Assuming reviewReplies is an array, we can probably just use !reviewReplies.includes(reviewReply) (I haven't tested that, though). |
david | |
There's a better way to wrap this: this.listenTo(reviewReply, 'saved', () => { reviewReplyDrafts = this.get('reviewReplyDrafts'); ... }); (saves one level … |
david | |
Same wrapping here as above. |
david | |
Leftover debug output? |
david | |
If you have the bindAll in initialize mentioned before, this can just pass in _updateHasDraft directly. |
david | |
Probably better to use this.get('reviewReplyDrafts').forEach(reviewReply => { ... }); We're slowly replacing a lot of underscore use with modern JS … |
david | |
You should be able to skip the truthy check here. isFunction will return false if it's undefined/null/etc. |
david | |
Please put a blank line between these two lines. |
david | |
This is nested very deep. Can we break this stuff out into its own function, and then maybe define the … |
david | |
We should probably save the value inside beforeEach instead of here when the suite is defined. |
david | |
We should probably save the value inside beforeEach instead of here when the suite is defined. |
david | |
Only one blank line here. |
david | |
We should probably save the value inside beforeEach instead of here when the suite is defined. |
david | |
We should probably save the value inside beforeEach instead of here when the suite is defined. |
david | |
We should probably save the value inside beforeEach instead of here when the suite is defined. |
david | |
This is a regular JS file for now, so the last item in an object shouldn't have a trailing comma. |
david | |
Add this line back please. |
david | |
Add a blank line between these two. |
david | |
This can just be: this.listenTo(view, 'fieldSaved', this.showBanner); |
david | |
Add a blank line between these two. |
david | |
Better to use listenTo: this.listenTo(this.model, 'saved', this.showBanner); |
david | |
Alignment is wacky here. Should look like: ```javascript } else if (state === RB.ReviewRequest.PENDING && this.model.get('hasDraft')) { BannerClass = DraftBannerView; … |
david | |
Should probably save the value inside beforeEach |
david | |
Should save the value inside beforeEach |
david | |
Unless we change this, it should be defined as const. This is also a great place to use dedent. |
david | |
Can you include an "Option Args" section here, explaining what can be in options? |
david | |
Should have a "Returns" section. |
david | |
We're moving away from _super because it's not reliable. Can you just use RB.FloatingBannerView.prototype.render.call? |
david | |
Formatting of this comment isn't correct. It should be one line summary, blank line, longer description, and then include an … |
david | |
Should have a one-line summary, then a blank line, then longer description. |
david | |
Please include an "Option Args" section. |
david | |
Dedent this 4 spaces. |
david | |
Can we line everything up after the (? |
david | |
Second line here should line up with the other !options in the conditional. |
david | |
Dedent this 4 spaces. |
david | |
"Attributes" should be capitalized. |
david | |
Type can be Backbone.View or string |
david | |
Add a blank line between these. |
david | |
Should just be jQuery for the type. |
david | |
Please include a doc comment here. |
david | |
If this is a backbone view (having el), it will also have a $el. |
david | |
"Attributes" should be capitalized. |
david | |
Indentation in these should be 4 spaces instead of 2. |
david | |
Needs a "Returns" section. |
david | |
This can use an ES6 template string: console.error(`Index (${index}) is out of range.`); |
david | |
Should have a summary/description format. You can probably just add a blank line after "Register an item." |
david | |
Indentation in these should be 4 spaces instead of 2. |
david | |
item isn't used outside of the loop, so I'd rather do: while (registryCollection.length > 0) { const item = registryCollection.pop(); … |
david | |
Probably better to use forEach instead of _.each. |
david | |
Description should be on the next line after the type. |
david | |
Indentation should be 4 spaces, not 2. |
david | |
Should use summary/description format. |
david | |
Please add a doc comment here. |
david | |
This can be elided, since it doesn't do anything. |
david | |
Trailing whitespace |
bolariinwa | |
Hey Sarah, I was wondering if the {} are redundant over here? So would it be () => RB.DraftReviewBannerView.instance.show());? |
Sudolicious | |
I remember saying that we should use this.$el.append |
bolariinwa |
-
-
You only need
&
if you want to specialize the parent selector e.g.:.foo { &.bar { // Equivalent to .foo.bar } }
So you can just do
> h1, > p { ...
. -
-
-
We only need the
[].join('')
in ES5 because it does not have multiline strings. You can just do:javascript: template: _.template(dedent` <h1><%- title %></h1> `),
-
-
This is going to run when the file is sourced, and so this object might not exist? We may want to store the default selector rather than the actual result of querying the selector. It also allows us to be lazy and only perform that query when necessary.
-
this
isundefined
here. The second object passed toBackbone.{...}.extend
is applied directly to the created object instead of its prototype.You will have to do:
if (!RB.UnifiedReviewBannerView._instance) { // ... }
- Commit:
-
59cce13b7b9f13451761a41b75b76f3ebadb37235f7b5d645e385796eb4e602494130e2afd19a8f4
- Diff:
-
Revision 2 (+339 -30)
Checks run (2 succeeded)
- Commit:
-
5f7b5d645e385796eb4e602494130e2afd19a8f4a58aef7aaeddec5f1c430ce9d4f3aceb38b35be8
- Diff:
-
Revision 3 (+391 -44)
Checks run (2 succeeded)
- Diff:
-
Revision 4 (+441 -44)
- Diff:
-
Revision 5 (+554 -33)
Checks run (2 succeeded)
- Testing Done:
-
+ Manual test cases:
+ 1. Review request draft by modifying description, testing done, information -> banner should turn green + 2. Review request draft by adding a file (through drag-and-drop and Update > Add File) -> banner should turn green + 3. Discard review request draft with button on unified banner -> banner should turn brown, review request discarded + 3. New review by adding comment in diff viewer -> banner should turn green + 4. Discard review with button on unified banner -> banner should turn brown, review discarded + 5. New review with header, general comment in review dialog -> banner should turn green + 6. Discard review in review dialog -> banner should turn brown, review discarded + 7. Review reply draft by adding review replies on one review -> banner should turn green + 8. Remove all text of review reply draft (empty string) -> review reply should be removed, banner should turn brown + 9. Review reply draft by adding review replies on multiple/all reviews -> banner should turn green + 10. Discard review reply drafts with button on unified banner -> banner should turn brown, all review replies discarded + 11. New review/review request and review replies added -> banner should turn green + 12. Discard with button on unified banner -> banner should turn brown, review and review replies discarded + + *reload case on all odd test cases
- Diff:
-
Revision 6 (+602 -33)
Checks run (2 succeeded)
- Diff:
-
Revision 7 (+913 -35)
Checks run (2 succeeded)
-
-
Hey Sarah, Great work so far!
I just wanted to clarify, I know that var is bound to the execution context, in this case the function. Wouldn'tlet
be more appropriate?let banner, pendingReview, reviewRequest;
Something similar to this^?
-
-
-
I think this description is a bit of a mouthful.
Would something like this be a more sufficient summary?
"A unified, multi-mode banner that provides basic support for publishing/editing/discarding, batch operations and more."
- Diff:
-
Revision 8 (+1263 -57)
Checks run (2 succeeded)
- Summary:
-
[WIP] Using Unified Review Banner feature flagUnified Review Banner Base Shell
- Description:
-
~ Unified Review Banner: Base Shell
~ The Unified Review Banner Base Shell sets the foundation for the Unified
+ Review Banner, which will eventually take over for the three banners + currently used for draft review requests, reviews, and review replies. ~ Right now I'm working on using the feature flag to replace the existing banners with the unified banner. I basically have it working to replace it (for draft reviews) and change the colour of the unified banner when it becomes a draft. However, I wasn't sure about the draft banner being shown how it was (a listener on the comment being saved shows the banner) and I wanted to understand how it all fits together better so I am still exploring that to see if there is a way I can improve it.
~ The banner tracks the draft state of review requests, reviews, and
+ review replies so it can be put into a draft mode where the banner + appears green when at least one draft exists. The banner makes use of + RB.FloatingBannerView
to allow the banner to float to the top of the+ screen when the user scrolls down. The new RB.Registry
model allows+ views like dropdowns, buttons, and Backbone views to be registered in + different locations on the banner. There are placeholders registered to + the different banner sections right now which will later be removed or + replaced when the functionality of the Unified Review Banner is fleshed + out further. + + Currently, the Unified Review Banner is only shown when the Unified
+ Banner feature flag is enabled, by appending the following code to + settings_local.py
:+ + ENABLED_FEATURES = {
+ 'reviews.unified_banner': True
+ }
+ - Testing Done:
-
+ Added new JS tests to test functionality added. All JS tests pass.
+ Manual test cases:
~ 1. Review request draft by modifying description, testing done, information -> banner should turn green ~ 2. Review request draft by adding a file (through drag-and-drop and Update > Add File) -> banner should turn green ~ 3. Discard review request draft with button on unified banner -> banner should turn brown, review request discarded ~ 3. New review by adding comment in diff viewer -> banner should turn green ~ 4. Discard review with button on unified banner -> banner should turn brown, review discarded ~ 5. New review with header, general comment in review dialog -> banner should turn green ~ 6. Discard review in review dialog -> banner should turn brown, review discarded ~ 7. Review reply draft by adding review replies on one review -> banner should turn green ~ 8. Remove all text of review reply draft (empty string) -> review reply should be removed, banner should turn brown ~ 9. Review reply draft by adding review replies on multiple/all reviews -> banner should turn green ~ 10. Discard review reply drafts with button on unified banner -> banner should turn brown, all review replies discarded ~ 11. New review/review request and review replies added -> banner should turn green ~ 12. Discard with button on unified banner -> banner should turn brown, review and review replies discarded ~ 1. Review request draft by modifying description, testing done, ~ information -> banner should turn green ~ 2. Review request draft by adding a file (through drag-and-drop and ~ Update > Add File) -> banner should turn green ~ 3. Discard review request draft with button on unified banner -> banner ~ should turn brown, review request discarded ~ 4. New review by adding comment in diff viewer -> banner should turn ~ green ~ 5. Discard review with button on unified banner -> banner should turn ~ brown, review discarded ~ 6. New review with header, general comment in review dialog -> banner ~ should turn green ~ 7. Discard review in review dialog -> banner should turn brown, review + discarded + 8. Review reply draft by adding review replies on one review -> banner + should turn green + 9. Remove all text of review reply draft (empty string) -> review reply + should be removed, banner should turn brown + 10. Review reply draft by adding review replies on multiple/all reviews + -> banner should turn green + 11. Discard review reply drafts with button on unified banner -> banner + should turn brown, all review replies discarded + 12. New review/review request and review replies added -> banner should + turn green + 13. Discard with button on unified banner -> banner should turn brown, + review and review replies discarded ~ *reload case on all odd test cases
~ *reload case (where on reload the correct banner state persists) tested
+ on all odd test cases
- Testing Done:
-
Added new JS tests to test functionality added. All JS tests pass.
Manual test cases:
1. Review request draft by modifying description, testing done, information -> banner should turn green 2. Review request draft by adding a file (through drag-and-drop and Update > Add File) -> banner should turn green 3. Discard review request draft with button on unified banner -> banner should turn brown, review request discarded 4. New review by adding comment in diff viewer -> banner should turn green 5. Discard review with button on unified banner -> banner should turn brown, review discarded 6. New review with header, general comment in review dialog -> banner should turn green 7. Discard review in review dialog -> banner should turn brown, review discarded 8. Review reply draft by adding review replies on one review -> banner should turn green 9. Remove all text of review reply draft (empty string) -> review reply should be removed, banner should turn brown 10. Review reply draft by adding review replies on multiple/all reviews -> banner should turn green 11. Discard review reply drafts with button on unified banner -> banner should turn brown, all review replies discarded 12. New review/review request and review replies added -> banner should turn green 13. Discard with button on unified banner -> banner should turn brown, review and review replies discarded *reload case (where on reload the correct banner state persists) tested
~ on all odd test cases ~ on all non-discard test cases - Diff:
-
Revision 9 (+1352 -58)
Checks run (2 succeeded)
-
-
-
-
-
This should probably be
#unified-banner-docked
.Same for other selectors: they should spell out the entire phrase.
-
-
.selector *
is super expensive.CSS selectors are applied right-to-left, so the
*
will match every DOM element and then the browser will check.selector
against every parent. -
-
-
-
Since
reviewReplyDrafts
is an Array, which is mutable, this needs to be a function:defaults() { return { hasDraft: false, // ... }; },
-
-
-
The arrow function should be aligned with the first argument.
The arrow functino should be
() => this._updateHasDraft()
. Making it multiline is overkill. -
Again, this should just be
hasDraft
.Also, we can rewrite this using
Backbone.Model.prototype.isNew()
.const hasDraft = (!this.get('reviewRequest').isNew() || !this.get('pendingReview').isNew() || !!this.get('reviewReplyDrafts').length)
-
-
-
-
-
-
-
This should be formatted as either:
this.listenTo(reviewReply, 'saved', () => { // ... }); // or this.listenTo( reviewReply, 'saved', () => { // ... });
(Probably the latter to avoid rightward drift.)
-
-
Instead of
_.findWhere
, why not:if (!_reviewReplyDrafts.includes(reviewReply))
_.findWhere
compares all attributes instead of just comparing for equality. Two models with the same ID will have the property thata == b
. -
This can be rewritten as:
this.listenTo( reviewReply, 'destroying', () => this.set('reviewReplyDrafts', _.reject( this.get('reviewReplyDrafts'), draft => draft.id === reviewReply.id)));
-
-
This should be formatted as:
this.listenTo(reviewReply, 'destroyed', () => this._updateHasDraft());
The
{
and}
are unnecessary for a single-line lambda. -
-
-
-
-
-
-
-
- Diff:
-
Revision 10 (+1406 -62)
- Added Files:
Checks run (2 succeeded)
-
I have a bunch of comments, but they're almost all very simple formatting issues. Great work!
-
-
-
This can be cleaned up a bit:
_.bindAll(this, '_updateHasDraft'); this.listenTo(reviewRequest.draft, 'saved destroy', this._updateHasDraft); this.listenTo(pendingreview, 'saved destroy', this._updateHasDraft);
-
-
-
I think it would be better to have multiple
const reviewReplyDrafts = ...
in each place that it's used. Right now you share this same variable between the function and two inner closures, which seems ripe for strange bugs. -
Assuming
reviewReplies
is an array, we can probably just use!reviewReplies.includes(reviewReply)
(I haven't tested that, though). -
There's a better way to wrap this:
this.listenTo(reviewReply, 'saved', () => { reviewReplyDrafts = this.get('reviewReplyDrafts'); ... });
(saves one level of indentation and a couple lines)
-
-
-
If you have the
bindAll
in initialize mentioned before, this can just pass in_updateHasDraft
directly. -
Probably better to use
this.get('reviewReplyDrafts').forEach(reviewReply => { ... });
We're slowly replacing a lot of underscore use with modern JS features like that.
-
You should be able to skip the truthy check here.
isFunction
will returnfalse
if it's undefined/null/etc. -
-
This is nested very deep. Can we break this stuff out into its own function, and then maybe define the registries in their own variable first before passing them into
create()
? Just to flatten the code a little bit. -
-
-
-
-
-
-
-
-
-
-
-
-
Alignment is wacky here. Should look like:
```javascript
} else if (state === RB.ReviewRequest.PENDING &&
this.model.get('hasDraft')) {
BannerClass = DraftBannerView;
} -
-
-
-
-
-
We're moving away from
_super
because it's not reliable. Can you just useRB.FloatingBannerView.prototype.render.call
? -
Formatting of this comment isn't correct. It should be one line summary, blank line, longer description, and then include an "Args" section explaining
isDraft
. -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Should have a summary/description format. You can probably just add a blank line after "Register an item."
-
-
item
isn't used outside of the loop, so I'd rather do:while (registryCollection.length > 0) { const item = registryCollection.pop(); item.get('$view').remove(); }
-
-
-
-
-
-
- Diff:
-
Revision 11 (+1476 -60)
Checks run (2 succeeded)
- Diff:
-
Revision 12 (+1481 -61)
Checks run (2 succeeded)
- Commit:
-
a58aef7aaeddec5f1c430ce9d4f3aceb38b35be848aa572b0ffb2f398329b3b797958eeb72d0edec
- Diff:
-
Revision 13 (+1481 -61)
Checks run (2 succeeded)
- Branch:
-
release-4.0.xmaster
- Commit:
-
48aa572b0ffb2f398329b3b797958eeb72d0edecd628caa47017432b6d01170ea094afa15f7d757c
- Diff:
-
Revision 14 (+1664 -143)
Checks run (2 succeeded)
- Diff:
-
Revision 15 (+1481 -61)