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

feat: approver pattern #5027

Draft
wants to merge 7 commits into
base: dev
Choose a base branch
from
Draft

feat: approver pattern #5027

wants to merge 7 commits into from

Conversation

kyranjamie
Copy link
Collaborator

@kyranjamie kyranjamie commented Mar 5, 2024

Building Leather at commit 90b1724

This PR adds the <Approver /> component as described in Notion.

Initial demo
2024-03-05-000124.mp4

Todo

  • Add tooltip to Header component
  • Figure out best way to handle success screens (maybe just a duplicate Approver)
  • Add friction to Approve button cc/ @fabric-8
  • Blocked: header is outside the container currently when window's resized, not sure if this is easy to fix with Pete's work?

@@ -0,0 +1,26 @@
import { css } from 'leather-styles/css';
Copy link
Contributor

Choose a reason for hiding this comment

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

Just a heads up, I meant to mention before, I have a <Footer in the containers branch we can eventually use instead of this

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Will that play nicely with the fixed positioning though?

Copy link
Contributor

Choose a reason for hiding this comment

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

The footers are all supposed to be sticky now. Ignore my Footer for now and go as planned and then we can see if we can refactor them to share.

They are also supposed to have a top border when the content above them is scrollable but I didn't implement that yet

title: 'Feature/Approver',

render: ({ children, ...args }) => (
<Flex maxW="390px" h="680px" border="1px solid lightgrey" overflowY="auto">
Copy link
Contributor

Choose a reason for hiding this comment

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

Mark has told me to make the popup height 600px. Is that good with you? Or do you think we should have it variable based on the popup type?

I found that popup.ts accepts dimensions but we don't use them

@@ -0,0 +1,22 @@
import { useEffect } from 'react';
Copy link
Contributor

Choose a reason for hiding this comment

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

This seems cool and maybe useful to me for dynamic height sizing which has proved tricky in containers.

I was trying to use calculated heights via variables which panda doesn't like and had considered using style so this is a good idea

@pete-watters
Copy link
Contributor

The Header issue you mentioned is resolved in my work so you should be OK 👍

Copy link
Contributor

@alter-eggo alter-eggo left a comment

Choose a reason for hiding this comment

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

💪 👍

@@ -197,6 +197,7 @@
"ecdsa-sig-formatter": "1.0.11",
"ecpair": "2.1.0",
"formik": "2.4.5",
"framer-motion": "11.0.8",
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

src/app/common/hooks/use-register-children.ts Outdated Show resolved Hide resolved
const slightPauseForContentEnterAnimation = createDelay(120);

export function ApproverAdvanced({ children }: HasChildren) {
const { isDisplayingAdvancedView, setIsDisplayingAdvancedView } = useApproverContext();
Copy link
Contributor

Choose a reason for hiding this comment

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

can there be multiple advanced views? if so it seems this will close/open all of them at once?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It isn't built to support this, and don't think we will @mica000 ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Maybe I proactively reject two Approver components?

Copy link

Choose a reason for hiding this comment

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

Correct, only one advanced view

Comment on lines +87 to +130
<Button variant="outline">Cancel</Button>
<Button>Approve</Button>
Copy link
Contributor

@alter-eggo alter-eggo Mar 6, 2024

Choose a reason for hiding this comment

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

thinking in most cases there will be just these cancel/approve btns no? maybe create them as default in Approver.Actions?
but this means we need to pass approve/cancel actions as props, so quite arguable

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is a tough one. I separated the actions (as prop) from the children, so we apply the button styles implicitly (flex with stretch) but adding the buttons themselves I'm not sure, maybe in some cases we want different ones?

Not sure how to handle exactly. Esp. if we have the animated confirm btn.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

In the case that we have behaviour such as in latest designs, e.g.

image

think it would need to be part of approver to share the state

@kyranjamie kyranjamie force-pushed the feat/approver branch 5 times, most recently from cb142fc to 12bcc8c Compare March 7, 2024 16:54
@mica000
Copy link

mica000 commented Mar 7, 2024

This is amazing!!!! 😍😍😍😍😍😍

I noticed we are using 12 + 24px in the margins and 12px between ItemLayout and heading:
Screenshot 2024-03-07 at 12 46 45

This is happening because we don't have the heading component in development, so the structure will naturally be different. Wondering what we could do to preserve the same values. Maybe adding 24px between heading and itemLayout and 24px around all the margin will solve it?

Image of how it is in designs:
image

Also, the heading has a placeholder icon to show a tooltip that is sometimes present. Curious on how we would handle that as well.
image
https://www.figma.com/file/2MLHeIeL6XPVi3Tc2DfFCr/%E2%9D%96-Leather-%E2%80%93-Design-System?type=design&node-id=8945-112587&mode=design&t=pKAQcmHCAYgjWfee-4

@kyranjamie
Copy link
Collaborator Author

Thanks Michelly.

I haven't made sure the margins are accurate yet, so good you point it out. think it might be best to put a min-height on the header element. Will come up with a god approach today and show you.

The margins should look visually identical to designs, but be aware of the changes made in these PRs #5014 #5024.

In Figma you've padded the ItemInteractive for the hover state, but if we build it like that then it gets complicated because we need to use "compound margins" on the container (12 + 12) and every other element to get the right spacing. See storybook for demo of this. Now we use pesudo elements for the background so the core element needs to adjustment and aligns by default.

@kyranjamie kyranjamie force-pushed the feat/approver branch 2 times, most recently from a546d71 to 9a5a12d Compare March 18, 2024 09:23
@kyranjamie kyranjamie force-pushed the feat/approver branch 4 times, most recently from 7b42ae5 to d54ded8 Compare April 1, 2024 15:44
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.

None yet

4 participants