-
Notifications
You must be signed in to change notification settings - Fork 293
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
Enhance/#6252 - Create the "Top cities driving traffic" key metric widget tile #7279
Enhance/#6252 - Create the "Top cities driving traffic" key metric widget tile #7279
Conversation
Build files for 5794203 have been deleted. |
Size Change: +215 B (0%) Total Size: 1.4 MB
ℹ️ View Unchanged
|
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 for your amazing work here, @hussain-t!
I have left a few minor comments for you to take a look, mostly reflecting on changes required after #7061 was merged.
Apart from the changes highlighted, I'd request a couple more changes:
- Could we add a test case or two for this widget, similar to
TopConvertingTrafficSourceWidget.test.js
? - Could we update the QAB (
Note 4
) and the PR description, since now we've confirmed that we're using plain text instead of navigational links?
Thank you!
assets/js/modules/analytics-4/components/widgets/TopCitiesWidget.js
Outdated
Show resolved
Hide resolved
assets/js/modules/analytics-4/components/widgets/TopCitiesWidget.js
Outdated
Show resolved
Hide resolved
assets/js/modules/analytics-4/components/widgets/TopCitiesWidget.js
Outdated
Show resolved
Hide resolved
export const Loading = Template.bind( {} ); | ||
Loading.storyName = 'Loading'; | ||
Loading.args = { | ||
setupRegistry: ( { dispatch } ) => { | ||
dispatch( MODULES_ANALYTICS_4 ).startResolution( 'getReport', [ | ||
reportOptions, | ||
] ); | ||
}, | ||
}; |
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.
Is there a reason we don't have VRT scenarios for the loading state?
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.
We don't have VRT scenarios for the loading state for any other KM widget stories. I didn't create it to follow other widgets. Apart from that, IMO, we don't need a VRT scenario for the loading state. cc @jimmymadon
assets/js/modules/analytics-4/components/widgets/TopCitiesWidget.stories.js
Outdated
Show resolved
Hide resolved
assets/sass/components/key-metrics/_googlesitekit-km-widget-tile.scss
Outdated
Show resolved
Hide resolved
assets/sass/components/key-metrics/_googlesitekit-km-widget-tile.scss
Outdated
Show resolved
Hide resolved
Fix typo. Export default 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.
Thank you for the kind updates here, @hussain-t!
I've left another small comment for your attention. Apart from them, could we update the QAB a bit further so that the QA team can view the widget in the dashboard since all widgets no longer appear unconditionally?
We should be good to go as soon as the above are addressed, thank you!
assets/js/modules/analytics-4/components/widgets/TopCitiesWidget.stories.js
Outdated
Show resolved
Hide resolved
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, brilliant work, @hussain-t!
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.
Thanks @hussain-t – this one is almost there, just a few points to address 👍
select( MODULES_ANALYTICS_4 ).getReport( topcCitiesReportOptions ) | ||
); | ||
|
||
const loading = useInViewSelect( |
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.
The in-view select variant is only intended for selectors that get reports since it will return undefined
unconditionally when not in view which would not be expected for a selector like hasFinishedResolution
which would never return anything other than a boolean. It could be used for other things too but it's essentially intended for guarding selectors that have resolvers and their respective side-effects.
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.
Thanks, I have updated it to use useSelect
. However, I have checked other KM widgets, and they use the useInViewSelect
selector, which needs to be addressed.
const [ title ] = fieldValue; | ||
|
||
return ( | ||
<p className="googlesitekit-km-widget-tile__table-plain-text"> |
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.
Lets extract this to a component since it will be used by others as well rather than relying on the same class name in each instance manually.
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 didn't extract it into a separate component since it will be used only in Cities and Countries. However, it's a good idea to extract it 👍
{ | ||
field: 'metricValues.0.value', | ||
Component: ( { fieldValue } ) => ( | ||
<strong>{ numFmt( fieldValue / totalUsers, '%' ) }</strong> |
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 consistent with other uses we have (except the ChangeBadge
) but the design only shows a precision of 1 decimal place whereas numFmt
defaults to 2. Let's update this for consistency with the design.
loading={ loading } | ||
rows={ rows } | ||
columns={ columns } | ||
zeroState={ ZeroDataMessage } |
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.
Not unique to this issue since I see it is following others, but zeroState
should be ZeroState
and expect an elementType
as is our convention. i.e. PascalCase = element type; camelCase = node.
We can fix this in a separate issue if you'd prefer, I'm just calling what I 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.
Good catch. I have incorporated the changes in this PR to save a few hours 😃
}; | ||
Ready.scenario = { | ||
label: 'KeyMetrics/TopCitiesWidget/Ready', | ||
delay: 250, |
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.
Let's not add delay
unless it's really needed for some reason, in which case let's annotate why.
const { rows = [] } = topCitiesReport || {}; | ||
|
||
const totalUsers = | ||
topCitiesReport?.totals?.[ 0 ]?.metricValues?.[ 0 ]?.value; |
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.
We're already destructuring from topCitiesReport above with a fallback, how about we do the same with totals
above as well? We'd still need some chaining here but it could be simplified a bit.
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, thanks @hussain-t !
Summary
Addresses issue:
Relevant technical choices
In this PR, we've made an update to improve our code's adherence to established React naming conventions.
We previously used the prop name
zeroState
for theMetricTileTable
component, which expected a function returning a React element (PropTypes.func). According to React conventions, we use PascalCase for component names and camelCase for nodes. Hence,zeroState
has been renamed toZeroState
to better reflect its nature as a function that returns a component.This refactor affects the
MetricTileTable
component and any other components or places in the code where this prop was used. The functionality remains unchanged, but the prop's name reflects its nature better.PR Author Checklist
Do not alter or remove anything below. The following sections will be managed by moderators only.
Code Reviewer Checklist
Merge Reviewer Checklist