Conversation
|
|
||
| import * as chromeHelpers from '../../helpers/chrome'; | ||
| import Popup, { colors } from '../popup'; | ||
| import { COLORS } from '../../constants/colors'; |
There was a problem hiding this comment.
I like the app caps constant.
| onChange={(e) => setColor(e.target.value)} | ||
| /> | ||
| <button type="submit">Save</button> | ||
| <label className="customForm--label">enter hexadecimal value</label> |
There was a problem hiding this comment.
TODO: get the for and id hooked up for the input.
| return ( | ||
| <div className="colorLinks"> | ||
| <span | ||
| <h1 |
There was a problem hiding this comment.
Preserve the nice visual indicator for the current color, but also let's remind users what extension they're using.
| </div> | ||
|
|
||
| {showCustomInput && <CustomInput color={activeColor} saveHandler={onColorChange} />} | ||
| <details> |
There was a problem hiding this comment.
Still need to refactor (remove?) the hook logic, since the sweet new <details> element makes this easy.
|
|
||
| /* variables | ||
| _________________________________________________________*/ | ||
| :root { |
There was a problem hiding this comment.
I would like to use css custom properties for all the color logic. Setting and getting them in a Chrome extension has proven a little more elusive than I expected. But this will at least help consolidate our style values.
|
|
||
| import * as chromeHelpers from '../../helpers/chrome'; | ||
| import Popup, { colors } from '../popup'; | ||
| import { COLORS } from '../../constants/colors'; |
| </div> | ||
|
|
||
| {showCustomInput && <CustomInput color={activeColor} saveHandler={onColorChange} />} | ||
| <details> |
| @@ -0,0 +1,2 @@ | |||
|
|
|||
| export const COLORS: Array<string> = ['#37d67a', '#2ccce4', '#06A77D', '#ff8a65', '#1E91D6'] No newline at end of file | |||
There was a problem hiding this comment.
We can turn prefer default export out.
There was a problem hiding this comment.
You know, I don't mind named imports. What do you think?
There was a problem hiding this comment.
I prefer them, to be honest. LETS BREAK THEM DOWN!
| expect(customForm.length).toEqual(0); | ||
| }); | ||
|
|
||
| it('should show custom input when no active color found', async () => { |
There was a problem hiding this comment.
Active color always exists, so I removed this test.
|
|
||
| expect(colorButtons[0]).toHaveClass('colorLinks--button active'); | ||
| expect(whiteList.length).toEqual(1); | ||
| expect(customForm.length).toEqual(0); |
There was a problem hiding this comment.
Custom form exists in the DOM now, even when it isn't visible.
| await waitFor(() => expect(customForm.length).toEqual(1), { container }); | ||
| }); | ||
|
|
||
| it('should show a custom input when the custom color button is clicked', async () => { |
There was a problem hiding this comment.
This functionality no longer exists.
| const ColorButton: FC<OwnProps> = ({ color, clickHandler, active }) => ( | ||
| <div> | ||
| <button | ||
| aria-label="save color" |
There was a problem hiding this comment.
We don't need an aria-label, since this is clearly an extension that assists people who can see, and this label would only benefit screen reader users.
| 'no-console': 'off', | ||
| 'comma-dangle': 'off', | ||
| 'implicit-arrow-linebreak': 'off', | ||
| 'import/prefer-default-export': 'off', |
There was a problem hiding this comment.
sortin things alphabetically
There was a problem hiding this comment.
and we prefer named imports 😄
Pull Request Test Coverage Report for Build 143157397
💛 - Coveralls |
| 'comma-dangle': 'off', | ||
| 'implicit-arrow-linebreak': 'off', | ||
| 'import/prefer-default-export': 'off', | ||
| 'jsx-a11y/control-has-associated-label': 'off', |
There was a problem hiding this comment.
This rule seems unnecessary to enforce since screen reader support doesn't seem necessary.
|
Wow @postrad, these are some really awesome upgrades! I love the new UI tweaks too. I did see one "bug" (if you will), where submitting a custom color would not "save", and wouldn't display "current color". Also, do you think it'd be helpful to support both |

The current UI isn't quite as intuitive as it could be. This PR aims to help fix that problem.
make "white list" feature's behavior clearerI think, after spending time with the UI during this PR, that this is out of scope. It deserves a PR of its own.
This is currently a work-in-progress. I still need to review open issues to see if this PR can address those any of those as well.