Skip to content
This repository was archived by the owner on Jan 14, 2025. It is now read-only.

fix(top-app-bar): foundation should be destroyed and reinitialized on variant change #519

Merged

Conversation

mgr34
Copy link
Contributor

@mgr34 mgr34 commented Dec 13, 2018

this should close issue #517. hope I didn't go overboard on the unit tests. As noted in discord I am having trouble getting screenshot tests to run. I have added a new one.


I signed it

@codecov-io
Copy link

codecov-io commented Dec 13, 2018

Codecov Report

Merging #519 into rc0.8.0 will increase coverage by 0.01%.
The diff coverage is 100%.

Impacted file tree graph

@@             Coverage Diff             @@
##           rc0.8.0     #519      +/-   ##
===========================================
+ Coverage    96.63%   96.64%   +0.01%     
===========================================
  Files           59       59              
  Lines         1991     1999       +8     
  Branches       239      241       +2     
===========================================
+ Hits          1924     1932       +8     
  Misses          67       67
Impacted Files Coverage Δ
packages/top-app-bar/index.js 100% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 160cf3a...4bf447a. Read the comment docs.

@moog16
Copy link

moog16 commented Dec 14, 2018

please water branch with rc0.8.0

Copy link

@moog16 moog16 left a comment

Choose a reason for hiding this comment

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

Haven't done a full review, but one comment so far.

@mgr34
Copy link
Contributor Author

mgr34 commented Dec 14, 2018

please water branch with rc0.8.0

I'm afraid I am not quite sure what you mean by water. Yesterday during my work on the PR I fell behind one commit. I merged that in this afternoon: 0af79bd

@@ -204,6 +204,111 @@ test('#enableRippleOnElement throws error if a native element', () => {
);
});

test('when changes from short to fixed the foundation changes', () => {
Copy link

Choose a reason for hiding this comment

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

wow great test coverage!

assert.exists(wrapper.instance().foundation_);
});

test('when changes from short to shortCollpased the foundation changes', () => {
Copy link

Choose a reason for hiding this comment

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

Shouldn't the foundation not change in this case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

From what I understand it should reinitialize. When init() is called on MDCShortTopAppBarFoundation it registers a resize handler if initialized as a short variant. If it begins life collapsed it would not be necessary to register the resize handler. [0] Alternatively the resize handler could simply be deregistered. But I think this would work just as well?

[0] https://github.com/material-components/material-components-web/blob/a487783c74a42104a27ed6de42bad9d6d29a0a63/packages/mdc-top-app-bar/short/foundation.js#L44-L56

Copy link

Choose a reason for hiding this comment

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

ah right - this is because you would want the short collapsed to immediately collapse. Good call. Thanks!

@moog16
Copy link

moog16 commented Dec 14, 2018

Rereviewed your changes!

Watering a branch is making it up to date with rc0.8.0 (the base branch)

@@ -69,10 +69,25 @@ export default class TopAppBar extends React.Component {
this.foundation_.destroy();
}

componentDidUpdate(prevProps) {
const foundationChanged = ['short', 'shortCollapsed', 'fixed']
.some((variant) => this.props[variant] !== prevProps[variant] );
Copy link

Choose a reason for hiding this comment

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

formatting issue, but for the sake of time I'm going to ignore this one and fix in a following pr

Copy link

@moog16 moog16 left a comment

Choose a reason for hiding this comment

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

Changes look good!

@moog16
Copy link

moog16 commented Dec 17, 2018

#537

@mgr34 please update your golden json file like in this commit

@moog16
Copy link

moog16 commented Dec 17, 2018

Also looks like the CLA isn't signed. Could you please sign the PR please.

@mgr34
Copy link
Contributor Author

mgr34 commented Dec 17, 2018

@moog16 thanks for the review. I have merged bb7765a to update golden.json.

I am afraid the CLA thing is a bit perplexing. I know it had been signed. But I see this morning that it was not verifying. However, after pushing the merge it seems to now be verifying the signature again.

@moog16
Copy link

moog16 commented Dec 17, 2018

Ya looks like its back to being green! Thanks :) I will merge it

@moog16
Copy link

moog16 commented Dec 17, 2018

@mgr34 please resolve conflicts

@moog16
Copy link

moog16 commented Dec 17, 2018

updated tests #539

@moog16 moog16 merged commit 689b792 into material-components:rc0.8.0 Dec 17, 2018
@moog16
Copy link

moog16 commented Dec 17, 2018

Tests passing in #539 and CLA signed #519 (comment)

moog16 pushed a commit that referenced this pull request Dec 28, 2018
moog16 pushed a commit that referenced this pull request Dec 28, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants