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
style: new toast design closer to SIP-34 #10178
Conversation
@@ -145,8 +145,11 @@ function SelectFilter({ | |||
data-test="filters-select" | |||
themeConfig={filterSelectTheme} | |||
stylesConfig={filterSelectStyles} | |||
// @ts-ignore |
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 seems I introduced these issues when I added https://github.com/vtaits/react-select-async-paginate in #10035 and this PR merely uncovered them (for some reason... 🤔). I'll address in another PR if it's possible, the types for that package are quite confusing.
8b67b9b
to
ceb0b76
Compare
37e653f
to
187776a
Compare
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'm a little concerned with how large the package-lock diff is here, i wouldn't expect the dep changes to cause such a large change. Can you validate to make sure this is correct?
superset-frontend/package.json
Outdated
@@ -61,14 +61,14 @@ | |||
"@emotion/core": "^10.0.28", | |||
"@superset-ui/chart": "^0.14.1", | |||
"@superset-ui/chart-composition": "^0.14.1", | |||
"@superset-ui/color": "^0.14.2", | |||
"@superset-ui/chart-controls": "^0.14.1", | |||
"@superset-ui/color": "^0.14.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.
were the downgrades here intentional?
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.
@etr2460 I didn't clean up conflict correctly. All package should be up to date now.
|
||
interface ToastPresenterProps { | ||
toast: { id: string; toastType: ToastType; text: string; duration: number }; | ||
onCloseToast: (arg0: string) => void; |
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 name this argument
|
||
const ToastPresenter = ({ toasts, removeToast }: ToastPresenterProps) => | ||
toasts.length > 0 && ( | ||
<StyledToastPresenter id="toast-presenter"> |
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 you think using a Portal for this might make it easier?
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.
Although looking at the diff, it seems like this was written like this before, so up to you if you want to see if a Portal is easier or not
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 I will keep this way
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.
thanks for fixing the package lock conflict, a couple more comments
@@ -97,13 +117,17 @@ class Toast extends React.Component { | |||
toastType === DANGER_TOAST && 'toast--danger', |
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.
Are these classes still needed? It looks like they're unused now
{toastType === SUCCESS_TOAST ? ( | ||
<Icon name="check" /> | ||
) : ( | ||
<Icon name="error" /> | ||
)} |
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.
Since we have a warning icon, should we use that for the WARNING_TOAST
s too? And perhaps add an info icon as well? If we don't add the info icon, should we perhaps default to no icon at all, since it could be confusing for an info toast to show an error icon
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 will prefer info toasts without Icon and warning toasts will have the same icon as error.
} | ||
`; | ||
|
||
type ToastType = |
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 is defined twice, let's pull it into a types.ts
file
under the License. | ||
--> | ||
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg"> | ||
<path fill-rule="evenodd" clip-rule="evenodd" d="M12 2C6.47715 2 2 6.47715 2 12C2 17.5228 6.47715 22 12 22C17.5228 22 22 17.5228 22 12C22 9.34784 20.9464 6.8043 19.0711 4.92893C17.1957 3.05357 14.6522 2 12 2Z" fill="#666666"/> |
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.
One more comment, I think you might need to default the fill
attribute to "currentColor"
so that we can override the color of the icon with CSS
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.
CSS rules end up overriding the property. However, it's best to be consistent and use currentColor
.
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.
ah, I see. I was using color
to change the icon's color and not fill
so it didn't work. Do we prefer to override this with color
or fill
on the icon? i was planning a change to the Icon component to get rid of styled
and use this method instead; with this then color
works:
const Icon = ({ name, color = '#666666', ...rest }: IconProps) => {
const Component = iconsRegistry[name];
return <Component color={color} {...rest} />;
};
export default Icon;
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.
color seems reasonable, as that's how the icon fonts behave. We should def try to use currentColor
for fill rules when it makes sense as it allows for the most flexibility.
62da4ba
to
2aba392
Compare
2aba392
to
8b6a7d6
Compare
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.
lgtm
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.
lgtm too. thanks for the iterations!
SUMMARY
This PR is still work in process but I'd like to have early feedback.
Toast
andToastPresenter
to typescripttoast.less
to emotion styleBEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Before
After
Success Toast
Error/Warning Toast
TEST PLAN
ADDITIONAL INFORMATION