Skip to content
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

MWPW-145574 - Dynamic Nav Gnav Implementation #2180

Merged
merged 5 commits into from
May 23, 2024

Conversation

JasonHowellSlavin
Copy link
Contributor

@JasonHowellSlavin JasonHowellSlavin commented Apr 22, 2024

Adds functionality to allow consumer projects to opt in to a dynamic nav experience. If a dynamicNavKey is registered in a consumer repo's config, this code adds logic to save the gnav source to sessionStorage allowing for the same nav experience in subsequent clicks.

  • entry pages will set gnavSource to sessionStorage is a gnav source meta tag is present
  • on pages will check for a gnavSource in sessionStorage, and if one is found, either modify the gnav-source meta tag, or create one
  • pages without the dynamic-nav metadata will do nothing or remove gnavSource from sessionStorage
  • projects without the key present, or where the key mismatches with the key saved in storage will use the default gnav experience

Context:
The wiki in the ticket provides more context, but it was desired by our stakeholders that this only be a single tab experience.

Based on comments in #2092 I am adding this PR as the approach and closing 2092.

Resolves: MWPW-145574

Test URLs:

Before: https://main--milo--adobecom.hlx.page/drafts/slavin/dynamic-nav/hugo-boss-case-study-entry?martech=off
After: https://dynamic-nav-gnav-impl--milo--jasonhowellslavin.hlx.page/drafts/slavin/dynamic-nav/hugo-boss-case-study-entry?martech=off
Before: https://main--bacom--adobecom.hlx.page/drafts/slavin/dynamic-nav/aem-rtcdp-entry?martech=off
After: https://dynamic-nav-gnav-impl-config--bacom--adobecom.hlx.page/drafts/slavin/dynamic-nav/aem-rtcdp-entry?milolibs=dynamic-nav&martech=off

To test:
Go to the second after link. On the Hugo Boss page
Observe the nav (pricing and resources)
Right click "watch now" and open in a new tab
Observe the nav is the default milo nav ("Explore")
From the Hugo Boss page left click "Watch Now" to open in the same tab
Observe the pricing and resources nav loads

@JasonHowellSlavin JasonHowellSlavin added the needs-verification PR requires E2E testing by a reviewer label Apr 22, 2024
Copy link
Contributor

aem-code-sync bot commented Apr 22, 2024

@mokimo mokimo requested review from salonijain3 and sharmrj April 23, 2024 10:06
@narcis-radu narcis-radu requested a review from bandana147 April 23, 2024 15:48
Comment on lines 953 to 957
let url = getMetadata('gnav-source') || `${locale.contentRoot}/gnav`;
if (dynamicNavKey) {
const { default: dynamicNav } = await import('../../features/dynamic-navigation.js');
url = dynamicNav(url, dynamicNavKey);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should probably have a new function getGnavSource (or something along those lines) that produces the url and contains all the logic for generating the url within it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with Raghav, we should extract it into a separate function that generates the URL.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. I am not so sure that I agree. The dynamic nav is an opt in feature requiring a consumer to update their config to have the dynamicNavKey in order to kick off the experience.

Though it may make the init function a bit cleaner, a function combining the two would mix both the default behavior and an opt in feature, which I am not certain aids in readability.

Interested to see what you think.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the future we may have logic added or subtracted from our hypothetical getSource function. init is and should be agnostic about the details of getting the url and that is communicated well by a separate function.

The separation between default and opt in behaviour can be communicated well enough in the function itself by the if statement you'll have to add. And the notion of what constitutes default vs non default behavior now and in the future is malleable enough that it makes sense to cordon it off from our main init logic so that it's clear in the future where gnav url generation logic should go.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I appreciate your thoughtful and full response! I see what you're saying. To be honest, I am still on the fence because it feels a bit like premature optimization and we'd be adding 3 lines of code by pulling these 5 out into a function.

Maybe @mokimo can weigh in since he recommended the approach.

Copy link
Contributor

@mokimo mokimo Apr 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sharmrj So you'd think something like this?

const getSource = async () => {
    const { locale, dynamicNavKey } = getConfig();
    let url = getMetadata('gnav-source') || `${locale.contentRoot}/gnav`;
    if (dynamicNavKey) {
      const { default: dynamicNav } = await import('../../features/dynamic-navigation.js');
      url = dynamicNav(url, dynamicNavKey);
    }
    return url
}

export default async function init(block) {
  try {
    const { locale, mep } = getConfig();
    const url = await getSource()
    const content = await fetchAndProcessPlainHtml({ url })
      .catch((e) => lanaLog({
        message: `Error fetching gnav content url: ${url}`,
        e,
        tags: 'errorType=error,module=gnav',
      }));
....

@sharmrj and @bandana147 are the new gnav code owners 😁 So if that's how they'd prefer it, no objections.

Since the init function is growing already, it does look pretty clean indeed, extracting it into a small helper

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup. That's what I was envisioning.

Copy link
Contributor Author

@JasonHowellSlavin JasonHowellSlavin Apr 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. I'll make those changes you requested @sharmrj. Any thoughts on modifying the unit tests? Since the function is called in init seems that the tests can remain as is.

I'll be sure to update the docs as well @mokimo.

Thank you both for your input!

@skumar09 skumar09 added the run-nala Run Nala Test Automation against PR label Apr 24, 2024
Copy link
Contributor

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.

Copy link
Contributor

@mokimo mokimo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the overall solution. It's an opt-in feature and only affects pages that actually use the feature.

It would be great if this can be added to the docs https://milo.adobe.com/docs/authoring/global-navigation

Copy link
Contributor

github-actions bot commented May 3, 2024

This PR is currently in the needs-verification state. Please assign a QA engineer to verify the changes.

Copy link
Contributor

This PR has not been updated recently and will be closed in 7 days if no action is taken. Please ensure all checks are passing, https://github.com/orgs/adobecom/discussions/997 provides instructions. If the PR is ready to be merged, please mark it with the "Ready for Stage" label.

@github-actions github-actions bot added the Stale label May 11, 2024
@mokimo
Copy link
Contributor

mokimo commented May 13, 2024

@JasonHowellSlavin what's the timing on this? Make sure to assign a QA/QE and have them apply the ready for stage label to take this forward

@github-actions github-actions bot removed the Stale label May 14, 2024
@Dli3 Dli3 added verified PR has been E2E tested by a reviewer and removed needs-verification PR requires E2E testing by a reviewer labels May 21, 2024
Copy link
Contributor

Reminder to set the Ready for Stage label - to queue this to get merged to stage & production.

@milo-pr-merge milo-pr-merge bot merged commit e74e21e into adobecom:stage May 23, 2024
12 checks passed
@milo-pr-merge milo-pr-merge bot mentioned this pull request May 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Ready for Stage run-nala Run Nala Test Automation against PR verified PR has been E2E tested by a reviewer
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants