Following information architecture situation:
- A communication site registered as hub site
- Another site (can be communications or modern teams site) associated with the hub site
- The associated site has some site info tagging; which is visualized to site visitors through a SPFx Header extension
- The hub site either does not have site info, or the values that it has are different from that in the associated site
Site associated with Hub; in this site via SPFx Header extension, some ‘site identification’ is visualized in the site’s header
From this hub-associated site, navigate to the hub site. The header info remains visible, even though the info does not hold for the hub site
Refresh / explicit (first)visit the hub site; then the ‘false-positive’ site info is gone
From first visit of hub, navigate to the associated site. The header info remains invisible, even though this site holds identifying site information
Cause: in an hub, only on 'first-visit' the SPFx Header(s) are executed
Inspecting the network traffic, it is evident that the displayed header info is not refreshed on navigating 'within hub context': the SPFx Header is not re-executed. Apparent only on explicit 'first-visit' to an Hub assocation - hub or associated site; then SPFxHeader components are executed. And on any navigation 'within' the hub; the (visual) state of the SPFxHeader is preserved; on same notice as the 'hub navigation.
For performance perspective, makes sense. But in situation where via SPFx Header extension essential site information is displayed, -- which is not per se similar throughout the entire hub association; the result in browser is functional / governance-wise incorrect.
UPDATE - problem resolved thanks to community
On friendly suggestion of Vesa Vujonen, I submitted our finding as SharePoint dev issue: Hub site on navigation preserves SPFx header display state of associated site. And the combined power of the community delivered; Andrew Connell suggested that it's related to the navigatedEvent & the page routers partial page loading, and referred to post of Elio Struijf in which similar behavior is described and solution provided: Handling navigation in a SharePoint Framework application customizer.
No comments:
Post a Comment