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

Tooltip improvements #91

Merged

Conversation

Chef-Cheems
Copy link
Contributor

In this PR:

  • hasTooltip prop for <Text /> to show dotted underline
  • Use object for useTooltip arguments instead of separate parameters.
  • Invert the theme of child components in the tooltip
  • Slight improvement to hover delayed hide logic.

// then prevent closing it.
clearTimeout(hideTimeout.current);
}
if (e.target === tooltipElement) {
Copy link
Contributor

Choose a reason for hiding this comment

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

else if here is better I think. What do you think?

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 doesn't really matter actually since its impossible for both conditions to be true at the same time (since target can't be 2 things at the same time). So mostly matter of taste, I personally think its easier to read without else if 🙂

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, true. I said it because of redundant check in runtime but if it is better readability I agree to stay it like this instead of little performance gain

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hm.... that's actually a good point, thanks! 👍
But yeah, maybe better to not over-optimize stuff for now for the sake of code readability, and there are probably other pieces of code that need optimization much more than this 🙂

I'm thinking of getting some really cheap phone and laptop someday to see how it all works on low-power devices, easy to forget that most users don't have latest and greatest hardware.

Copy link
Contributor

Choose a reason for hiding this comment

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

I am also a fan of avoiding else if at all cost. Easier to read, less bugs, easier to test.

Comment on lines 26 to 31
${({ theme, hasTooltip }) =>
hasTooltip &&
`
text-decoration: underline dotted ${theme.colors.textSubtle};
text-underline-offset: 0.1em;
`}
Copy link
Contributor

Choose a reason for hiding this comment

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

This is coupling the Text component with Tooltip. I think it is better to create a component in the tooltip that uses <Text /> or do it at the project level.

Copy link
Contributor

Choose a reason for hiding this comment

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

For example export a TooltipText 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.

@hachiojidev hm.... how about just renaming the prop to something more generic like underlined or dotted-underlined? Seems a bit excessive to create a separate component for the same component with such little difference. 🤔

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think it is excessive. This is a very specific style.

text-decoration: underline dotted ${theme.colors.textSubtle};
text-underline-offset: 0.1em;

const tooltipHoverRef = useRef(false);
const tooltipHoverTimeoutRef = useRef<number>();
const isHoveringOverTooltip = useRef(false);
const hideTimeout = useRef<number>();
Copy link
Contributor

Choose a reason for hiding this comment

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

useRef<typeof setTimeout>

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yep, fixed. Can't wait when TS will start understanding if its browser or node project 🙁

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh shit, CI pipeline didn't like the types.... ugh...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, something is different between FE repo and Toolkit TS compilation.
I'm aware of the return typeof setTimeout thing, used it myself here and you used it here (btw I just noticed you use typeof setTimeout but you actually need typeof setInterval, although it doesn't really matter I guess).
In this repo TS is not ok with that during rollup build, even though it shows no problems in VSCode.

Anyway, I chose to specifically use browser's window.setTimeout that returns plain old number instead of complicated NodeJS Timeout type that is not applicable in browser anyway. It actually makes a bit more sense to me since this code is not supposed to be run outside of browser anyway, and in browser its setTimeout returns just number.

// then prevent closing it.
clearTimeout(hideTimeout.current);
}
if (e.target === tooltipElement) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I am also a fan of avoiding else if at all cost. Easier to read, less bugs, easier to test.

Comment on lines +1 to +9
import styled from "styled-components";
import Text from "./Text";

const TooltipText = styled(Text)`
text-decoration: ${({ theme }) => `underline dotted ${theme.colors.textSubtle}`};
text-underline-offset: 0.1em;
`;

export default TooltipText;
Copy link
Contributor

Choose a reason for hiding this comment

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

This is exactly what I was thinking...but exported from the Tooltip. No worries, we can think about alternative solutions later.

@hachiojidev hachiojidev merged commit 78ac0df into pancakeswap:master May 3, 2021
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

3 participants