-
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
Header
component adjustements
#357
Conversation
Implemented `Layout` component to account `Header` into router's scope for `NavLink` component support used in `Navigation` component
✅ Deploy Preview for acre-dapp-testnet ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Header
component adjustementsHeader
component adjustements
With proposed approach it's redundant to wrap each page with `Layout` component - it's handled by the wrapper route.
77a7bb2
to
a06c1de
Compare
dapp/src/components/Header/index.tsx
Outdated
// TODO: To be adjusted after project cleanup | ||
const NAVIGATION_ITEMS: NavigationItemType[] = [ | ||
{ label: "Home", href: routerPath.home }, | ||
{ label: "Activity", href: `${routerPath.activity}/1` }, |
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 link should redirect to shared layout for activity so in my opinion we don't need the activity id here (1
).
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.
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
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.
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.
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.
Addressed comments
dapp/src/DApp.tsx
Outdated
<DocsDrawer /> | ||
</> | ||
) | ||
return <RouterProvider router={router} /> |
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.
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.
Answered under mentioned comment
leftIcon={<Icon as={BitcoinIcon} boxSize={6} />} | ||
onClick={handleConnectBitcoinAccount} | ||
<AnimatePresence initial={false}> | ||
{(isConnected || !isHomeRoute) && ( |
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.
Generally, in such cases, we set the condition higher and return null
if it does not meet the condition.
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.
It's not true with <AnimatePresence />
component. It requires the render condition to be explicitly defined inside it to capture the rerender.
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.
Ok, so let's create AnimatePresence
as a standalone wrapper with children
prop and move there this condition.
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.
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} /> |
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.
Do we want to pass items props instead of importing navigation items directly in the Navigation
component?
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.
Why not. It makes Navigation
reusable.
It might not be needed in our particular case but who knows.
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.
Addressed comments
leftIcon={<Icon as={BitcoinIcon} boxSize={6} />} | ||
onClick={handleConnectBitcoinAccount} | ||
<AnimatePresence initial={false}> | ||
{(isConnected || !isHomeRoute) && ( |
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.
Ok, so let's create AnimatePresence
as a standalone wrapper with children
prop and move there this condition.
const containerVariants: Variants = { | ||
hidden: { opacity: 0, y: -48 }, | ||
visible: { opacity: 1, y: 0 }, | ||
} |
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 believe we can move containerVariants
to theme
dir.
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'd like to keep animation related variables coupled together. Will not make it.
export type NavigationItemType = { | ||
label: string | ||
href: string | ||
} |
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.
Let's move this type to types/nav.ts
/types/navigation.ts
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.
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.
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.
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.
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.
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
display="block" | ||
fontSize="md" | ||
lineHeight="md" | ||
fontWeight="bold" | ||
mb={2} | ||
color="grey.500" | ||
_activeLink={{ color: "grey.700" }} |
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.
Maybe it's worth considering defining these styles in the theme
?
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.
Ref commit: bea88fc
dapp/src/components/Header/index.tsx
Outdated
// TODO: To be adjusted after project pivot/cleanup | ||
const NAVIGATION_ITEMS: NavigationItemType[] = [ | ||
{ label: "Season 1", href: routerPath.home }, | ||
{ label: "Dashboard", href: routerPath.overview }, | ||
] |
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.
Let's create components/Header/Navigation/NavigationItem.ts file and move there this NAVIGATION_ITEMS
.
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.
Ref commit: 599a8907
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.
export function Link(props: LinkProps) { | ||
return <ChakraLink as={RouterLink} {...props} /> | ||
} |
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.
Let's separate these two components into two files Link
for the Link component and NavLink
for NavLink
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.
Ref commit: 4ffdb22
<ListItem key={item.href} pos="relative"> | ||
<NavLink |
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.
Let's move this logic to components/Header/Navigation/NavigationItem.ts file.
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.
Ref commit: cc68712
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.
Ref commit: 599a8907
Don't see any new commits on the list(https://github.com/thesis/acre/pull/357/commits), did you push them? :)
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.
Switching navigation looks great 🚀 I have left just a small comment, which can be improved later if needed.
export { default as Navigation } from "./Navigation" | ||
export { default as NavigationItem } from "./NavigationItem" |
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.
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.
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.
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 😆
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">
Ref: #355
Goal:
To adjust
Header
component following latest design changesDone:
Link
andNavLink
components, a fusion of Chakra's and Router'sLink
componentNavigation
component with animated active item indicatorConnectWallet
component with presence animation