-
Notifications
You must be signed in to change notification settings - Fork 295
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
Error state for individual Key Metric Widget Tiles #7310
Comments
Hi @10upsimon, nice work so far here on the IB front. A few notes:
|
Much appreciated @techanvil, I am iterating based on your last reply. |
@techanvil I have updated the IB to include:
I've also updated the POC PR to include examples of such
Thank you for your continued thoroughness! |
Thanks @10upsimon! Nice work here, happy to give this the old LGTM and move over to the EB. 🎉 IB ✅ |
QA Update: ✅Verified:
Note: the |
Feature Description
Key Metric widget tiles are much smaller than our usual widgets and hence require new error components to be designed as per the Figma mocks.
This issue was split out from #7149 since point 2 in that issue's AC was making things quite complicated.
This issue (#7310) focuses on implementing the error state for individual KMW tiles as per the following screenshot:
The more complicated scenario which "combines" the error state together in the rare case that all widget tiles throw an error will be tackled in #7311:
Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance criteria
ReportErrorActions
component invalidating the resolution of the selectors that threw an error thereby attempting to resolve those selectors again.ReportErrorActions
component and use thegetErrorTroubleshootingLinkURL
selector.Implementation Brief
ℹ️ POC Pull Request
Please note that due to the nature of discovery for IB on this issue, code changes were naturally explored. As a result a POC pull request was opened demonstrating a fully working error state for the
<LoyalVisitorsWidget>
component. Please see #7324. Please note, however, that this is merely a proof of concept and should be taken merely as a guideline for implementation.While the existing
<WidgetReportError>
could potentially be utilised and will correctly render an error message, error description and correct "Retry" handler, it will not display and format the contents in a means that satisfies the Figma design for a single key metric widget error state.Looking into the
<WidgetReportError>
component, and ultimately the<ReportError>
component (used by the<WidgetReportError>
component), the following components could be utilised when creating a new error component for Key Metrics Widget tiles:<CTA>
and<ReportErrorActions>
. These two components can be combined within said new error component, and be styled as per the Figma design. The CTA component will need to be updated in order to receive the header text/label text above the error title, described in more detail below.The following guidelines should be followed to satisfy this issue:
<MetricTileError>
component that is to be rendered in place of the contents of a Key Metrics Widget tile when an error state is encountered.error
the error object passed directly from the individual Key Metric Widget tile component, should an error occur.headerText
the header text/label text to be rendered above the loading error title within the error component, which will likely be thetitle
prop of the key metric widget in question that is erroring. This can be named accordingly as the author sees fit, as long as it is retained throughout the steps to follow.moduleSlug
the moduleSlug passed down from the kmw tile, necessary as the base tiles such asWidgetTileNumeric
may not be used for a single module slug only.assets/js/components/KeyMetrics/MetricTileError.js
<CTA>
,<ReportErrorActions>
.<CTA>
and<ReportErrorActions>
components. The newheaderText
prop (see sections to follow around updating the CTA component) should be passed to the<CTA>
component. Theerror
prop as received in the<MetricTileError>
component should be forwarded to the<CTA>
component, and thetitle
prop of the<CTA>
component should be hard coded to__( 'Data Loading Failed', 'google-site-kit' )
as per the Figma design.<ReportErrorActions>
component nested within the<CTA>
component, themoduleSlug
anderror
props as received by the<MetricTileError>
component should be forwarded to the<ReportErrorActions>
component, i.eerror={ error } moduleSlug={ moduleSlug }
.<MetricTileError>
component and it's elements according to the Figma design. Use the existing SASS files (and add as necessary) atassets/sass/components/key-metrics
. Add necessary wrapper elements to target/override CSS styling rules, take note that the elements within the flex box will need to wrap, and the order of the button and help text elements should be reversed.<MetricTileError>
component in the POC PR.<CTA>
component (located atassets/js/components/notifications/CTA.js
) to accept a newheaderText
prop, to be used to render pre-title heading/label text as per the Figma design. Said prop should be of typestring
, default to''
and be rendered prior totitle
(if present) in an applicable element wrapper.<CTA>
component in the POC PR.getErrorForSelector
method within auseSelect
implementation using theMODULES_ANALYTICS_4
module.<LoyalVisitorsWidget>
component in the POC PR here and here.assets/js/modules/analytics-4/components/widgets
with the above logic to check for errors, and pass the error as anerror
prop on the final key metric widget return component, i.eerror={ error }
. AmoduleSlug
prop should also be passed to the the final key metric widget return component so that correct retry actions can be executed if an error state is encountered, and saidmoduleSlug
should be the slug of the module in which the widget is being rendered within, i.e"analytics-4"
for the<LoyalVisitorsWidget>
. However, given this is defined at the singular KMW tile level, and passed down to the eventual<MetricTileError>
component.<MetricTileNumeric>
,<MetricTileTable>
and<MetricTileText>
. Within each of these components, the newly addederror
andmoduleSlug
props should be forwarded to the final<WidgetTileError>
component. See such a change to the<MetricTileNumeric>
in the POC PR here.error
prop of type oneOfPropTypes.arrayOf( PropTypes.object )
orPropTypes.object
, and amoduleSlug
prop of typePropTypes.string.isRequired
. Theerror
prop should not be required.error
object (via theerror
prop), said widget should render the<MetricTileError>
component, forwarding thetitle
,error
,headerText
andmoduleSlug
props as passed to said widget rendering the<MetricTileError>
component.📚 New Story State/Scenario Requirements (Including VRT Validation)
Given that the error states for individual Key Metrics Widgets are new, existing stories should be updated to include error state stories, each with a VRT scenario.
The following current stories need updating to include error states:
assets/js/modules/analytics-4/components/widgets/LoyalVisitorsWidget.stories.js
assets/js/modules/analytics-4/components/widgets/NewVisitorsWidget.stories.js
assets/js/modules/analytics-4/components/widgets/PopularContentWidget.stories.js
assets/js/modules/search-console/components/widgets/PopularKeywordsWidget.stories.js
assets/js/modules/analytics-4/components/widgets/TopConvertingTrafficSourceWidget.stories.js
assets/js/modules/analytics-4/components/widgets/TopTrafficSourceWidget.stories.js
For each of the existing stories above, the following should be undertaken:
Error
story with accompanying scenario should be created.dispatch
object used by existing story argsdispatch().receiveError()
for inspiration, as used in unrelated stories such asassets/js/modules/analytics/components/dashboard/DashboardOverallPageMetricsWidgetGA4.stories.js
Once Error states have been created, validate that they appear as part of the VRT tests suite. Visual references will likely need to be added as this will be the first run of VRT tests for said Error states within the above stories.
Test Coverage
VRT Test
Unit Tests
QA Brief
In order to successfully QA the outcome of this issue, a proxy will be required in order to modify HTTP responses and force error states within various components. The Tweak Google Chrome extension should be installed and activated prior to proceeding. Once installed and activated, perform the following steps:
userInput
andga4Reporting
feature flags.URL
input:^(.*)\/wp-json\/google-site-kit\/v1\/modules\/(.*)$
GET
but that the response code is set to400
.Response Payload
to be as follows:Toggle on the rule via the play icon near the top of the extension window. The final state of the Tweak extension window should look as follows:
Application
tab of the Chrome developer tools console:Changelog entry
The text was updated successfully, but these errors were encountered: