-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
fix(MM-49742): broken user avatar #8356
Conversation
@@ -44,10 +44,10 @@ const Image = ({author, forwardRef, iconSize, size, source, url}: Props) => { | |||
const lastPictureUpdateAt = author ? getLastPictureUpdate(author) : 0; | |||
const fIStyle = useMemo(() => ({ | |||
borderRadius: size / 2, | |||
backgroundColor: theme.centerChannelBg, | |||
backgroundColor: changeOpacity(theme.centerChannelColor, 0.12), |
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.
@matthewbirtch per request
by just adding a 12% opacity center channel color fill
Only helps if the image is transparent. If the image is the same color as centerChannelColor, then you'd have the same problem.
I will fix test as soon as I know that this is the right fix. |
@rahimrahman are we able to conditionally change the background color? The reason I ask is that it doesn't show up well in all themes on the profile screen. See screenshot below for example. If it appears on Is this possible? |
@matthewbirtch the biggest challenge here is the backgroundcolor for the Image is buried 2-3 children deep.
And the Image component is where I'm setting the background. ParentComponent or GrandParentComponent is the one with the backgroundColor for the entire container, so in order for the Image component to distinguish what backgroundColor is being used from the ParentComponent or GrandParentComponent, we would have to pass the prop down a few levels (prop drilling). I won't be able to use React context either since changing the backgroundColor based on the ParentComponent or GrandParentComponent will cause changes to all profile images. What if we do what Elias suggested?
This would isolate the issue only on tab bar, but understandable, this might still be an issue in post, etc.
|
Sorry for the delayed reply @rahimrahman. I'd rather not have a border on the profile image at all times. I'd rather go back to what we had previously in the original: #8356 (comment) |
It's only on the tab bar. Not all the time. |
Ok, I think this should be ok then. Let's do it |
…ttom tab bar * status size reduced to 12 from default 14 * the size of the profile photo has been reduced from 28 to 22 to be inline with other icons on tab bar
|
||
const profilePicture = wrapper.getByTestId('account-profile-picture'); | ||
|
||
expect(profilePicture.props.author.email).toContain('@simulator.amazonses.com'); |
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.
This is one of the few consistent data from the fakeUser method. This is just to make sure the observable is working.
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.
To make the test more "stable" and a bit more intention revealing, you could add to the database a new user, and set the current user id to that user. That way you don't have to rely on "the few consistent data from the fakeUser method".
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.
Make sense too. Thank you for your feedback. Although the goal of this is to ensure that the prop author
receive an object of UserModel
. I could check that it is not undefined
because currentUser can be.
Now that I think about it, I should think about currentUser being undefined
in Account, however since I'm mocking ProfilePicture, it will not mean a thing.
I can also check that the author
has a few keys, like email, firstName & lastName. What the values are irrelevant.
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.
Nothing blocking, but a few things to consider.
})); | ||
|
||
const Account = ({currentUser, isFocused, theme}: Props) => { | ||
export const Account = ({currentUser, isFocused, theme}: Props) => { |
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 am not a big fan of exporting stuff just for testing, since they can be inadvertently imported.
My approach is either test everything on the exported interface, or export a new object (exportsForTest
or something like that) with all the elements you want to export only for testing purposes.
It is dirty and ugly, but helps not importing things that shouldn't be imported in other files.
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.
@larkox isn't this the same as creating two separate files, one for Account component and the second one only with database with observables? Account component will be tested separately, and the file with database observables will be test separately as well.
Would that be more ideal? That way I'm not exporting just for testing, but exporting to be imported inside observable.
My approach is either test everything on the exported interface
I like unit testing in isolation and in the most atomic level. 1) Account component and 2) with observable, to show what each parts will do. Thus the reason why I had 2 different describe
.
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.
Having two different files seems more "the way we do things". It still opens the door to importing the wrong component, but it is less common (it is easier to notice that you are importing something like: components/myComponent/myComponent
).
I don't disagree with your claim of "testing in isolation and in the most atomic level", but it is something to be careful about, since it can be driven to the absurd. For example, you could consider that each callback is an atomic part, and should be tested separately, and your component will look like the following:
export const myCallback1 = (prop1, prop2, state1, state2, setState1, setState2) => {...};
export const myCallback2 = (prop1, state1, setState2) => {...};
const MyComponent = (prop1, prop2) => {
const [state1, setState1] = useState();
const [state2, setState2] = useState();
const c1 = useCallback(() => myCallback1(prop1, prop2, state1, state2, setState1, setState2));
const c2 = useCallback(() => myCallback2(prop1, state1, setState2));
return (...);
}
export default MyComponent;
With your approach here, you are creating a new "implementation detail separation" between the component and the with observable. And what I mean with an "implementation detail separation" is that the component will never be used without the with observable. Even if in code they can be separate, logically they are an inseparable atomic thing.
That being said, that approach can also gotten to the absurd and say that the whole app is an atomic inseparable thing, and we should only the test the app as a whole.
In summary... I don't disagree on making this cut as long as it makes testing easier, but as a rule of thumb I would try to make the test of the whole component (state and component, not state on one side and component on the other).
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.
Understood. I see your points. I have been invited and accepted to join the testing team and will bring this up to see where we can find common grounds. In the meantime, I will leave it as it is, with the knowledge that Account now can be imported as a component without observables, and eventually it should and it could (as part of design components).
|
||
const profilePicture = wrapper.getByTestId('account-profile-picture'); | ||
|
||
expect(profilePicture.props.author.email).toContain('@simulator.amazonses.com'); |
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.
To make the test more "stable" and a bit more intention revealing, you could add to the database a new user, and set the current user id to that user. That way you don't have to rely on "the few consistent data from the fakeUser method".
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
@matthewbirtch hi, reminder to review the result of the changes that we agreed upon. Here are two screenshots to make it easier to see. |
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.
Looks good. Thanks @rahimrahman
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.
Hi @rahimrahman
there is a crash occuring when I open channel, on iphone and android device
I'll DM the test server creds
I'm not sure is related to this PR. @larkox would this be related to the work you did around the components to display in the settings screen or something? |
This is almost sure something related to the prop validation PR I added. Merging main into this PR should fix it. |
/update-branch |
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.
Thank you Rahim.
No blockers on the changes. The bug exists and might have a fix from Daniel. I'll follow up on that.
Summary
Blank user avatar "hides" menu option.
Ticket Link
Fixes: https://mattermost.atlassian.net/browse/MM-49742
Checklist
E2E iOS tests for PR
.Device Information
This PR was tested on: iPhone 15 Simulator, iOS 17.4.1
Screenshots
Added unit test to Account:
Release Note