-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
[RNMobile] Remove third-party dependency on react-native-hsv-color-picker #53329
[RNMobile] Remove third-party dependency on react-native-hsv-color-picker #53329
Conversation
…ve-hsv-color-picker
Size Change: 0 B Total Size: 1.51 MB ℹ️ View Unchanged
|
@dcalhoun Let me know if you have any thoughts on the testing strategy here. Initially, I had planned to add tests to the ColorPicker component simply because it didn't have tests. While writing the tests, I realized the ColorPicker functionality was mostly covered by tests that already existed, like this Cover block test, so this test may not be needed. At any rate, I don't think I've mocked the test setup correctly -- I was trying to avoid initializing the full editor by just testing the ColorPicker itself. If we do decide to keep this test, perhaps it's better to initialize the full editor here? |
41d1443
to
20ae378
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.
Nice work! Thank you for helping address this complexity.
I'd like to test the implementation on physical devices and review the larger files more thoroughly, but I wanted to share initial feedback now. I'll follow up later.
@dcalhoun Let me know if you have any thoughts on the testing strategy here. Initially, I had planned to add tests to the ColorPicker component simply because it didn't have tests. While writing the tests, I realized the ColorPicker functionality was mostly covered by tests that already existed, like this Cover block test, so this test may not be needed.
Good catch. I might describe this decision as unit testing (ColorPicker
) vs integration testing (ColorPicker
via Cover edit). I think there is an argument for either approach. I also think there is a balance as to how many tests we have, i.e. should we test both the unit (ColorPicker
alone) and integration (ColorPicker
within Cover and Buttons)?
Most of our current tests target edit components, rather than specific units within them. So, my thought is testing via Cover and Buttons edit makes sense; keeping in mind that we may should consider avoiding writing identical test cases in both locations.
That said, ColorPicker
is a complex unit, used a in a few different places. If we want to unit test it, I could understand that.
Lastly, we also have a pattern of testing subjects that cut across numerous locations. E.g. editor history tests are placed in a top-level location as it relates to several different edit components. My thought is that color picking doesn't reach this level of ubiquity, but I'm open to thoughts on that.
Co-authored-by: David Calhoun <github@davidcalhoun.me>
Co-authored-by: David Calhoun <github@davidcalhoun.me>
…://github.com/WordPress/gutenberg into rnmobile/remove-react-native-hsv-color-picker
@dcalhoun Thanks for the detailed review! I've added some comments, with the only question I had on this comment. The rest of the feedback I either implemented or agreed with. 👍 |
Removes Color Picker test in favor of testing the color picker in a deeper editor tree, like Cover block
@dcalhoun I think this one should be ready to review again. Let me know if you have further feedback! 🙇 |
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 looks good! Thank you for completing this. I tested the performance using prototype builds and did not note any degradations.
Flaky tests detected in 4dea3b1. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5995112427
|
Related:
Todo:
What?
Replaces the forked version of react-native-hsv-color-picker in favor of implementing the library within Gutenberg instead.
Why?
To reduce the number of third-party libraries and dependencies in order to better support React Native's New Architecture and simplify the React Native upgrade process for Gutenberg Mobile.
How?
The PR takes the source of our forked react-native-hsv-color-picker code, and reimplements the source within the Color Picker component. The new HSV components (
HuePicker
,SaturationValuePicker
) are just UI interfaces that leverage the librariestinycolor2
andreact-native-linear-gradient
, which are conveniently already dependencies of the project.Testing Instructions
Screenshots or screencast
Screen.Recording.2023-08-04.at.3.46.51.pm.mov