Create an onReady and onError callback for standalone gnav

[bandana147]

• Adds an onReady callback that will be triggered when Gnav loads
• Adds an onError callback that will be triggered if any error occurs inside gnav

Resolves: MWPW-158168

Test URLs:

• Before: https://main--milo--adobecom.hlx.page/?martech=off
• After: https://gnav-event--milo--adobecom.hlx.page/?martech=off

Qa: https://adobecom.github.io/nav-consumer/navigation.html?authoringpath=/federal/dev&env=stage&navbranch=gnav-event

[AEM Code Sync]

Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch and validate page speed.
In case there are problems, just click a checkbox below to rerun the respective action.

• Re-run PSI checks
• Re-sync branch

Commits

• 76d8f71 ✅ (latest)
• ba18c20 ✅
• 35bebf5 ✅
• 7c05c59 ✅
• 9c13956 ✅
• 027c4ae ✅
• 987f3fd ✅
• 8ffd316 ✅
• 55511bd ✅
• 16f1822 ✅
• 0501658 ✅

[AEM Code Sync]

	Page	Scores	Audits	Google
📱	/?martech=off
🖥️	/?martech=off

[Codecov]

Codecov Report

Attention: Patch coverage is 74.54545% with 14 lines in your changes missing coverage. Please review.

Project coverage is 96.22%. Comparing base (8da3683) to head (ba18c20).
Report is 1 commits behind head on stage.

Files with missing lines	Patch %	Lines
libs/utils/utils.js	0.00%	11 Missing ⚠️
libs/navigation/navigation.js	86.95%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##            stage    #2873      +/-   ##
==========================================
- Coverage   96.24%   96.22%   -0.02%     
==========================================
  Files         237      237              
  Lines       54219    54243      +24     
==========================================
+ Hits        52182    52195      +13     
- Misses       2037     2048      +11     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mokimo]

Suggested change

	window.dispatchEvent(new CustomEvent('feds:nav.ready'));
	window.dispatchEvent(new CustomEvent('feds:nav:ready'));

[mokimo]

On another note, since it's a milo block, should we dispatch milo:globalnav:ready ? That follows the other eventlisteners such as milo:modal:closed within the ecosystem

[mokimo]

As a more general question, why is that needed and what is the use-case? The ticket and description don't mention anything

[bandana147]

As a more general question, why is that needed and what is the use-case? The ticket and description don't mention anything

@mokimo This is currently required for the Adobe Home team, but we thought it would be a good use case to support as a standalone component. They want to display a loader state until the Gnav fully loads and be able to handle/track any errors that occur within their app.

[sharmrj]

Since this is an async function couldn't the consumers just do

 try {
  // do stuff
  await loadBlock(...);
  // do more stuff
} catch (e) {
  // handle error
}

Or they could even do

loadBlock(...).then(onReady).catch(onError)

of course you'd have to await the initBlock function inside bootstrapper.js for this to work correctly (

milo/libs/navigation/bootstrapper.js

Line 31 in af28174

initBlock(document.querySelector(targetEl));

).

This would allow us to avoid the rigmarole of callbacks and events that add more complexity to our model of how the global-navigation works. We'd just have to throw irrecoverable errors for the consumer to deal with (you may have to modify loadPostLCP with a try...catch to make milo correctly 'consume' global-navigation).

I realize I might be missing some nuance related to what errors should be propagated vs which errors should be handled internally, but my understanding is that the global-navigation already does this adequately; we'd need only to remove the try catch block in the global navigation init function, and modify the consuming end to handle the error (loadPostLCP in milo's case)(https://github.com/adobecom/milo/blob/af281740d8e910d0e677e3fb556f11c7095aeb50/libs/blocks/global-navigation/global-navigation.js#L1029C1-L1047C4)

Ultimately I think it's better to deal with this problem by propagating exceptions and dealing with exceptions on the consuming end rather than muck around with events and callbacks. Some time back we refused to allow Partner Portals to emit events to signify when specific parts of the global-navigation were loaded #2583 , and I think the same concerns apply here.

[bandana147]

If we implement it this way, the consuming client will receive the onError callback only when the gnav content is not found.
All other errors, such as IMS issues or errors loading fragments, would be logged internally. To achieve this we could add a console.error line here
Thoughts? @narcis-radu @mokimo @salonijain3

[GitHub Actions]

This pull request is not passing all required checks. Please see this discussion for information on how to get all checks passing. Inconsistent checks can be manually retried. If a test absolutely can not pass for a good reason, please add a comment with an explanation to the PR.

[bandana147]

@narcis-radu @mokimo Could you please review the updated changes?