Allow standalone Gnav client to Integrate their own Unav in Standalone Gnav

[bandana147]

Hi Team,

Adobe Home, a consumer of Standalone Gnav, has requested the ability to integrate their own Unav. As the owners of Unav, they believe this would simplify updates and feature integrations. Currently, they must rely on Gnav to implement updates or features, causing delays. They propose Gnav serve as a container, allowing them to manage Unav independently while taking responsibility for end-to-end testing. While we’ve emphasized maintaining consistency across all Standalone Gnav clients, they remain persistent.
I’d like to hear your thoughts on this request.

I did a due diligence the decoupling and this is how it looks - https://github.com/adobecom/milo/compare/gnav-unav
We give them a flag which would disable our usual unav setup and give them a container instead and it would be on them to insert the unav in that container like we do today for search container.

Test app link - https://adobecom.github.io/nav-consumer/navigation.html?authoringpath=/federal/home&navbranch=gnav-unav&self-unav=true

[mokimo]

This topic sounds familiar, didn't we already have a similar discussion? I would personally not recommend this. This will open the box for any (standalone) consumer to render their own unav and makes QA virtually impossible on your end.

It's not just about the unav team testing changes either. Adobe home might be on UNAV v1.6 without you being ready for it, while all other consumers are on v1.4. Now you release changes in milo that are incompatible with v1.6 (which u don't even know is being used) and you have a CSO. And it will be you that's "liable" for those CSOs, as you own the global navigation & need to ensure it always runs as expected.

On top of that, there are the mentioned consistency issues. If the issue is efficiency/speed, IMO you should sync with the team and seeing on how you can shorten integration times for new versions and evaluate how this is currently a bottleneck and affects business.

[overmyheadandbody]

I fully agree with @mokimo's points. Could they simply define the Unav version that the Gnav should use via a config? They could use that for their use-case. If something breaks during their testing, it also means the new version introduces some breaking changes that should be communicated to other consumers.

[bandana147]

@mokimo I completely agree with you on this. However, they want to have the container and take full ownership of it. This means that even if they are using version 1.6, standalone GNav will not make any changes to support it. It will be entirely their responsibility to ensure it works.

For standalone GNav, if you opt for this approach, it will result in an empty UNav metadata, meaning it will not be rendered in our Milo code.

That said, I still agree that if any CSO issues arise due to their changes in UNav, the FEDS team would still be held accountable.

@salonijain3 Thoughts on this?

[amitbikram]

Allowing consumers to render their own UNAV would create significant QA challenges and consistency issues. The risk of version mismatches, like Adobe Home using UNAV v1.6 while others are on v1.4, could lead to unexpected behaviour, CSOs, with liability falling on us as owners of the global navigation. Instead of this, we should focus on improving integration times for new versions and addressing efficiency bottlenecks to better support the business.

[salonijain3]

I wanted to add more context on this, we are getting more unav enhancements like below that are needed for other universal nav clients like Adobe home but not used by adobe.com.

• https://jira.corp.adobe.com/browse/MWPW-167523 : Profile menu complex config is not exposed in standalone navigator
• https://jira.corp.adobe.com/browse/MWPW-163946 : Bypass UNC related config from clients
• https://jira.corp.adobe.com/browse/MWPW-159217 : Add support for Jarvis through Unav and make appID of notifications configurable
• https://jira.corp.adobe.com/browse/MWPW-159143 : Add isSectionDividerRequired feature support to gnav

The testing of unav when unav team adds more features like above is adding to the maintainance of unav + gnav, So, we are hoping that we can decouple unav from gnav in the standalone gnav version. The version used by adobe.com, the milo version will remain as-is.

This is also a request by Adobe home as they want to integrate with the unav version much earlier than the timelines of adobe.com which would be possible if they self integrate as Unav is owned by the Adobe home team.
If clients opt for self-integration, we will not be responsible for testing, and the CSOs and liability will be owned by the team that chooses to self-integrate.
This will be updated in the standalone integration wiki and will be discussed with self integrated unav clients like Adobe Home : https://wiki.corp.adobe.com/pages/viewpage.action?spaceKey=WEBT&title=Standalone+Navigation+Integration+Guide
@amitbikram @narcis-radu Let me know your thoughts on this.