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

Header component adjustements #357

Merged
merged 24 commits into from
Apr 30, 2024
Merged

Header component adjustements #357

merged 24 commits into from
Apr 30, 2024

Conversation

kpyszkowski
Copy link
Contributor

@kpyszkowski kpyszkowski commented Apr 15, 2024

Ref: #355

Goal:

To adjust Header component following latest design changes

Done:

  • Implement generic Link and NavLink components, a fusion of Chakra's and Router's Link component
  • Implement Navigation component with animated active item indicator
  • Added conditional rendering for ConnectWallet component with presence animation

Implemented `Layout` component to account `Header` into router's scope
for `NavLink` component support used in `Navigation` component
@kpyszkowski kpyszkowski marked this pull request as draft April 15, 2024 18:31
Copy link

netlify bot commented Apr 15, 2024

Deploy Preview for acre-dapp-testnet ready!

Name Link
🔨 Latest commit 78b0814
🔍 Latest deploy log https://app.netlify.com/sites/acre-dapp-testnet/deploys/6620fe0bcc8e6e0008de5d09
😎 Deploy Preview https://deploy-preview-357--acre-dapp-testnet.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@kpyszkowski kpyszkowski changed the title Draft: Header component adjustements Header component adjustements Apr 15, 2024
@kpyszkowski kpyszkowski self-assigned this Apr 15, 2024
With proposed approach it's redundant to wrap each page with `Layout`
component - it's handled by the wrapper route.
@kpyszkowski kpyszkowski marked this pull request as ready for review April 15, 2024 23:45
@kpyszkowski kpyszkowski requested a review from ioay April 15, 2024 23:45
// TODO: To be adjusted after project cleanup
const NAVIGATION_ITEMS: NavigationItemType[] = [
{ label: "Home", href: routerPath.home },
{ label: "Activity", href: `${routerPath.activity}/1` },
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 this link should redirect to shared layout for activity so in my opinion we don't need the activity id here (1).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's only a mock for testing as TODO indicates. The target pages and routing will be completely different after project's pivot.
Updated comment to be more descriptive, ref commit: b02de09

Copy link
Contributor Author

@kpyszkowski kpyszkowski Apr 17, 2024

Choose a reason for hiding this comment

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

Currently it's still not completely functional. Active state of the link is estimated incorrectly because of hardcoded activity id. I might need to create separate page without the URL segment only for mock.

I didn't do that but tested.
As designs indicates Navigation will only display Season and Dashboard links so dynamic URL segments won't be used, however it's confirmed to be working with parent route created.

The table presents how active state works with dynamic URL segments.

Copy link
Contributor Author

@kpyszkowski kpyszkowski left a comment

Choose a reason for hiding this comment

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

Addressed comments

r-czajkowski
r-czajkowski previously approved these changes Apr 17, 2024
<DocsDrawer />
</>
)
return <RouterProvider router={router} />
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Answered under mentioned comment

leftIcon={<Icon as={BitcoinIcon} boxSize={6} />}
onClick={handleConnectBitcoinAccount}
<AnimatePresence initial={false}>
{(isConnected || !isHomeRoute) && (
Copy link
Contributor

Choose a reason for hiding this comment

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

Generally, in such cases, we set the condition higher and return null if it does not meet the condition.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's not true with <AnimatePresence /> component. It requires the render condition to be explicitly defined inside it to capture the rerender.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, so let's create AnimatePresence as a standalone wrapper with children prop and move there this condition.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure why, it's pointless. It will cause the code to shadow. AnimatePresence as a part of Framer Motion has enough semantic meaning. No need to make it a wrapper.

<Icon as={AcreLogo} w={20} h={12} />
<Navigation items={NAVIGATION_ITEMS} />
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we want to pass items props instead of importing navigation items directly in the Navigation component?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why not. It makes Navigation reusable.
It might not be needed in our particular case but who knows.

Copy link
Contributor Author

@kpyszkowski kpyszkowski left a comment

Choose a reason for hiding this comment

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

Addressed comments

@kpyszkowski kpyszkowski changed the base branch from main to landing-page April 18, 2024 11:43
@kpyszkowski kpyszkowski marked this pull request as draft April 18, 2024 12:57
@kpyszkowski kpyszkowski marked this pull request as ready for review April 18, 2024 12:57
leftIcon={<Icon as={BitcoinIcon} boxSize={6} />}
onClick={handleConnectBitcoinAccount}
<AnimatePresence initial={false}>
{(isConnected || !isHomeRoute) && (
Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, so let's create AnimatePresence as a standalone wrapper with children prop and move there this condition.

Comment on lines +16 to +19
const containerVariants: Variants = {
hidden: { opacity: 0, y: -48 },
visible: { opacity: 1, y: 0 },
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I believe we can move containerVariants to theme dir.

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'd like to keep animation related variables coupled together. Will not make it.

Comment on lines 6 to 9
export type NavigationItemType = {
label: string
href: string
}
Copy link
Contributor

@ioay ioay Apr 22, 2024

Choose a reason for hiding this comment

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

Let's move this type to types/nav.ts/types/navigation.ts

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Component related types should be coupled with components. Granularity and separation of concerns is fine unless it's structurally clear. This type definition is not multipurpose nor reusable. It's tightly coupled with the component and it should be held with component or alternatively in separate file close to the component like <ComponentName>.types.ts. Will not make it.

Copy link
Contributor

Choose a reason for hiding this comment

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

So if it's not multipurpose nor reusable why do we export this type?
In case when we use types in other files we should do it from the types directory that is intended for this purpose. Thanks to this, we prevent creating redundant types in the future, in other places that may want to use such a type. If we use export type we should move it to types.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's just a props type definition. I don't see any other type definition in types directory.
It's strictly component related. Spreading it across multiple catalogs makes it difficult to find.

In this particular case props can simultaneously act as navigation item type definition so I can eventually approach it another way around and treat it as props type definition.
Ref commit: 2a9b31a

Comment on lines 39 to 45
display="block"
fontSize="md"
lineHeight="md"
fontWeight="bold"
mb={2}
color="grey.500"
_activeLink={{ color: "grey.700" }}
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe it's worth considering defining these styles in the theme?

Copy link
Contributor Author

@kpyszkowski kpyszkowski Apr 22, 2024

Choose a reason for hiding this comment

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

Ref commit: bea88fc

Comment on lines 8 to 12
// TODO: To be adjusted after project pivot/cleanup
const NAVIGATION_ITEMS: NavigationItemType[] = [
{ label: "Season 1", href: routerPath.home },
{ label: "Dashboard", href: routerPath.overview },
]
Copy link
Contributor

@ioay ioay Apr 22, 2024

Choose a reason for hiding this comment

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

Let's create components/Header/Navigation/NavigationItem.ts file and move there this NAVIGATION_ITEMS.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ref commit: 599a8907

Copy link
Contributor

Choose a reason for hiding this comment

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

Comment on lines +19 to +21
export function Link(props: LinkProps) {
return <ChakraLink as={RouterLink} {...props} />
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's separate these two components into two files Link for the Link component and NavLink for NavLink

Copy link
Contributor Author

@kpyszkowski kpyszkowski Apr 22, 2024

Choose a reason for hiding this comment

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

Ref commit: 4ffdb22

Comment on lines 36 to 37
<ListItem key={item.href} pos="relative">
<NavLink
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's move this logic to components/Header/Navigation/NavigationItem.ts file.

Copy link
Contributor Author

@kpyszkowski kpyszkowski Apr 22, 2024

Choose a reason for hiding this comment

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

Ref commit: cc68712

Copy link
Contributor

Choose a reason for hiding this comment

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

Ref commit: 599a8907

Don't see any new commits on the list(https://github.com/thesis/acre/pull/357/commits), did you push them? :)

@kpyszkowski kpyszkowski requested review from ioay, kkosiorowska and r-czajkowski and removed request for ioay April 25, 2024 10:08
Copy link
Contributor

@kkosiorowska kkosiorowska left a comment

Choose a reason for hiding this comment

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

Switching navigation looks great 🚀 I have left just a small comment, which can be improved later if needed.

Comment on lines 1 to 2
export { default as Navigation } from "./Navigation"
export { default as NavigationItem } from "./NavigationItem"
Copy link
Contributor

Choose a reason for hiding this comment

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

Some time ago we discussed the names and directory structure for components. Some of them are described here.

I believe that it would be good for us to have one approach together and keep a kind of order. So I'm wondering if the index.tsx file should not export the main component. The name of the directory indicates this and this component uses NavigationItem inside. That's why I'm thinking about it. The above solution puts these components a bit as sibling components. I'm curious about your opinion.

Copy link
Contributor Author

@kpyszkowski kpyszkowski Apr 30, 2024

Choose a reason for hiding this comment

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

Actually that's a good catch to remove NavigationItem export. NavigationItem shouldn't be used as a standalone part of the UI. It's just a child of Navigation and with that said it should be used only in parent component. That's why I removed this export, ref commit: 689154b

About the index files - generally speaking it hurts me a little to be honest 🤷🏻‍♂️
Because I have a huge problem to keep the source code in index files.
As the name suggests, they are used for indexing - so to organise exports, namespacing.

And you can get stuck with several files open at the same time, all with the same name (index.ts). It is then difficult to maintain it and traverse through the code.

What I have proposed is, in my opinion, the ideal spot, because:

  • we have one component per file,
  • the file name reflects the content
  • there is namespacing which means everything is oriented around the Navigation by including it in a common directory
  • imports are consistent and we get rid of unreadable "../Navigation/Navigation" paths

About the module/default export it's a topic to discuss. I don't have a preference here, maybe slightly leaning towards default exports.
However my definitive conclusion is to stop writing code in index files.
Index file is for indexing - full stop 😆

@kkosiorowska kkosiorowska merged commit e1b8d0a into landing-page Apr 30, 2024
20 checks passed
@kkosiorowska kkosiorowska deleted the header-navigation branch April 30, 2024 14:29
@nkuba nkuba mentioned this pull request May 3, 2024
kkosiorowska added a commit that referenced this pull request May 9, 2024
Closes: #363 

## Goal:
To implement Landing Page
This PR aggregates all component PRs to finally complete the
implementation of landing page

## Component PRs:
The list of PRs is given in the issue's description. Each component PR
merges to this PR.

- #357
- #358
- #364
- #368
- #369

## Designs:
<img width="1205" alt="image"
src="https://github.com/thesis/acre/assets/11503879/be6b6ed2-a808-483e-9daf-43d2c042cba4">
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