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

Fix sidenavs not redering for lovell facility pages #226

Merged
merged 4 commits into from
Nov 2, 2023

Conversation

jtmst
Copy link
Contributor

@jtmst jtmst commented Oct 31, 2023

Description

Relates to #14745. (or closes?)

Testing done

Local visual testing

Screenshots

Screen Shot 2023-10-31 at 1 54 59 PM Screen Shot 2023-10-31 at 1 55 27 PM

QA steps

Navigate to lovell pages (/lovell-federal-health-care-tricare/stories/)
Verify that sidenav is rendering
Verify that links are correct with no duplicates
Verify that non-lovell page sidenavs are unchanged (/butler-health-care/stories/)

Is this PR blocked by another PR?

  • Add the DO NOT MERGE label
  • Add links to additional PRs here:

@va-cms-bot va-cms-bot temporarily deployed to Tugboat October 31, 2023 17:57 Destroyed
@jtmst jtmst changed the title tests Fix sidenavs not redering for lovell facility pages Oct 31, 2023
src/lib/drupal/lovell/utils.ts Outdated Show resolved Hide resolved
src/lib/drupal/facilitySideNav.ts Outdated Show resolved Hide resolved
return {
description: item.description,
expanded: item.expanded,
label: item.title,
links: nestedItems,
url: { path: item.url },
fieldMenuSection: item.field_menu_section || null,
Copy link
Contributor

Choose a reason for hiding this comment

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

CONSIDER
I think I'd prefer this to not be field.... A big part of the formatter step, I think, is to move away from the Drupal-specific naming. Maybe menuSection or just section. Or, if this is only for Lovell and likely only ever will be, then maybe lovellSection?

Copy link
Contributor

Choose a reason for hiding this comment

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

completely agree here. lovellSection feels appropriate, and clearer for future debuggers

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Makes sense to me, fixed

@@ -133,3 +133,34 @@ export function isLovellBifurcatedResource(
isLovellFederalResource(resource as LovellBifurcatedFormattedResource)
)
}

export function getLovellVariantOfMenu(menu, variant: LovellVariant) {
Copy link
Contributor

Choose a reason for hiding this comment

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

SHOULD
I think we should likely define a type for menu.

Also, noting here because it's semi-related, but not related to code from this PR (I noticed it when examining what a type definition for menu might look like): buildSideNavDataFromMenu (and, more specifically, the function it calls, normalizeMenuData) is not handling Lovell correctly. This is the data that comes from that call:

{
  rootPath: "/lovell-federal-health-care-tricare/stories/",
  data: {
    name: "Lovell Federal health care - TRICARE",
    ....
    ....
    ...
  },
}

The name of the Lovell menu should be the Federal name, likely. It's different than all the others in that it has three top-level items. This is just grabbing the first one, which is TRICARE. It might not ultimately matter, but it is technically not correct, and might make things confusing. Or, perhaps, this should not be setting a name at all at this point. I don't want to put a ton of specific business logic in at this layer, so I'd love to see this more generally handle menu data rather than assuming that there's only one top-level item. I think we (@jtmst, @ryguyk, @tjheffner) might want to sync up on this and chat about some of the architectural implications.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Going to leave this as is to be addressed in future issue per this discussion: https://dsva.slack.com/archives/C01SR56755H/p1698932592500079

Comment on lines 149 to 163
// Filter arrays
if (Array.isArray(menu)) {
return menu
.map((item) => getLovellVariantOfMenu(item, variant))
.filter((item) => item !== null)
}

// Filter objects
const newData = {}
for (const key in menu) {
const filteredData = getLovellVariantOfMenu(menu[key], variant)
if (filteredData !== null) {
newData[key] = filteredData
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure about this. Let's sync up and discuss some things.

Copy link
Contributor

Choose a reason for hiding this comment

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

I understand what's going on here, but it feels a bit weird to me. It took me a bit to wrap my head around why there's "Filter arrays" and "Filter objects". I think that kind of muddies the situation a bit. It doesn't seem like we'd ever need to worry about objects separately, as the recursion should always be on the links property.

The following code might not be perfect, as it depends on some of the other restructuring that we discussed, but it seems to me that this function should look something like this (general idea):

  return menu
    .filter(
      (menuItem) =>
        menuItem.fieldMenuSection === variant ||
        menuItem.fieldMenuSection === 'both'
    )
    .map((menuItem) => ({
      ...menuItem,
      links: getLovellVariantOfMenu(menuItem.links, variant),
    }))

Copy link
Contributor Author

@jtmst jtmst Nov 2, 2023

Choose a reason for hiding this comment

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

Updated this logic for clarity, thanks for the feedback

@va-cms-bot va-cms-bot temporarily deployed to Tugboat November 2, 2023 14:28 Destroyed
@va-cms-bot va-cms-bot temporarily deployed to Tugboat November 2, 2023 14:29 Destroyed
@jtmst jtmst requested review from ryguyk and tjheffner November 2, 2023 14:47
Copy link
Contributor

@tjheffner tjheffner left a comment

Choose a reason for hiding this comment

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

this feels cleaner, thank you

Copy link
Contributor

@ryguyk ryguyk left a comment

Choose a reason for hiding this comment

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

Looks good. We'll likely continue to tweak some of this, per our ongoing conversations, but this is a good place to leave this. Nice work!

@tjheffner tjheffner merged commit 78c085e into main Nov 2, 2023
3 checks passed
@tjheffner tjheffner deleted the 14745-lovell-sidenavs branch November 2, 2023 15:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants