-
Notifications
You must be signed in to change notification settings - Fork 6
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
feat: Implement page footer with USWDS components #1285
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for veda-ui ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
renamed old footer to PageFooterLegacy
I suppose the content will be included in the new footer component
Contributes to the feature branch #1285 Hej @snmln ! Thanks for setting up the feature branch and foundations for the new footer component! I renamed the old footer to PageFooterLegacy, that way we can use the regular import path for our new footer component. Also added a .env var that allows us to switch between old and new footer implementations easily. Campground Rule[^1]: While working on the feature flag, I addressed an unrelated lint warning within the files I made changes to. [^1]: Always leave the campground cleaner than you found it.
**Related Ticket:** _{link related ticket here}_ ### Description of Changes Creating slim footer. - Establishing initial Front-end - Creating footer object model in veda.config.js - Setting up initial default.config.js - Wiring up Config data flow - Turning USWDS breakpoints on TO DO's for this PR: - Implement dynamic creation of links in footer component
@faustoperez Can you take a look at the preview view here: https://deploy-preview-1285--veda-ui.netlify.app/ We have the front-end in place and are currently working through functionality. So this should be in a good spot for a design review. |
@AliceR I have corrected the issues on the nextjs instance. Heads up on one of the bullet points:
This is an issue with the content section not respecting the |
import PageFooter from './index'; | ||
|
||
const mockMainNavItems: NavItem[] = navItems.mainNavItems; | ||
const mockSubNavItems: NavItem[] = navItems.subNavItems; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These mocks are mocking what looks to be used for the Header which includes dropdowns which footer doesn't worry about, we should probably explicity define the config for footer separately. And then test the dynamicness?
interface PageFooterProps { | ||
//use of NavItem is causing issues with TS and throwing erros in the . | ||
mainNavItems: (NavLinkItem | DropdownNavLink | ActionNavItem)[]; | ||
subNavItems: (NavLinkItem | DropdownNavLink | ActionNavItem)[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont think Footer will need DropDowns. Unsure if we have any designs where it includes dropdowns but I've never seen and I dont see the option in storybook here so we should probably remove this DropdownNavLink
type and then I made a note above about explicitly defining a config just for footer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AliceR and I determined that it makes sense to reuse the main and sub navigation for the footer navigation and strip out the dropdown options functionality within the footer. So we need to maintain the dropdown types to appropriately digest the existing navigation for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes more sense to be explicit hence why we have these config driven nav/menus and why we created it like so but thats fine. I'll add a note for this to be re-looked at in #1323 .
app/scripts/components/common/page-header/nav/create-dynamic-nav-menu-list.tsx
Show resolved
Hide resolved
…Components-Footer
Co-authored-by: Gjore Milevski <dzole0311@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the spirit of not wanting to drag this out any longer, this looks good to me. Related to dropdowns i've just updated this #1323 to address it since its not a blocker. There are issues with lint and test in the built which will need to be fixed before merging otherwise 👍🏼 and great work!
settings={footerSettings} | ||
mainNavItems={mainNavItems} | ||
subNavItems={subNavItems} | ||
hideFooter={hideFooter} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
curious, whats the point of having the hideFooter
prop?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its a carry over functionality from the old footer. No real documentation to back up its use. But I would infer that certain instances may not want to show this veda footer for some reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is for the case that the instance wants to have their own footer. ex. ghg has their own footer https://github.com/US-GHG-Center/veda-config-ghg/blob/bf3e66b7299d474dae01576e850bccaaaca5856c/overrides/components/page-footer/component.tsx#L136
@@ -0,0 +1,156 @@ | |||
import React, { useMemo } from 'react'; | |||
import { Icon } from '@trussworks/react-uswds'; | |||
import { DropdownNavLink, FooterSettings, NavLinkItem } from 'veda'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry.. just catching this now but we need to be decoupling from any parcel/virtual modules/(parcel-resolver-veda) dependency for the new architecture.
Its fine for legacy (because it still depends on parcel) to reference these types from here but for new components for refactor - we should be referencing from this file. Feel free to move those types to a more common directory to be shared between Footer and Header. (Header for example)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI to help out, there has been an ongoing effort since the very beginning of when this refactor work started and is still going on (see current PR) to remove these veda virtrual modules/parcel dependencies for new architecture.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, I updated this import to go from the common common/types.d.ts
level since these types are leveraged in multiple areas.
@@ -64,7 +71,8 @@ function LayoutRoot(props: { children?: ReactNode }) { | |||
useEffect(() => { | |||
// When there is no cookie consent form set up | |||
!cookieConsentContent && setGoogleTagManager(); | |||
}, []); | |||
// eslint-disable-next-line react-hooks/exhaustive-deps | |||
}, []); // Empty dependency array ensures this effect runs only once, and not during SSR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't layout-root
only used for the legacy way?
id='return-to-top-container' | ||
className='margin-left-auto margin-right-auto' | ||
> | ||
<USWDSButton |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This button doesn't move the focus of keyboard back to the top.
'mobile-lg': false, | ||
'desktop': false | ||
|
||
'mobile-lg': true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did we figure out if this change is needed?
gap: themeVars.$veda-uswds-spacing-105; | ||
} | ||
|
||
#return-to-top-container { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am seeing some styles using IDs, Was the specificity of ID needed for the style?
(Also, can some of these styles can be replaced with utility classes?)
Related Ticket: #1135
Description of Changes
TO DO:
Checkin with Fausto on progress.Notes & Questions About Changes
{Add additonal notes and outstanding questions here related to changes in this pull request}
Validation / Testing
{Update with info on what can be manually validated in the Deploy Preview link for example "Validate style updates to selection modal do NOT affect cards"}