-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Site editor: preset custom color duplicates #40837
Conversation
Check the slugs for the highest id number and add one.
Adding tests for getNameForPosition()
Size Change: +3.97 kB (0%) Total Size: 1.23 MB
ℹ️ View Unchanged
|
Tested well for me on a quick run, will give it a better test in the morning. |
Update doc comments Co-authored-by: Glen Davies <[email protected]>
Thanks @glendaviesnz |
Works great, @ramonjd. And even if you append whitespaces after the number, the order is maintained. |
Thanks for testing that scenario @javierarce! Glad you did. It hadn't occurred to me 😇 |
It would be good to fix this, but as it is already an issue on trunk, and a bit of an edge case, I agree that it could be looked at in a separate PR. |
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.
Worked as advertised for me
…gutenberg into try/custom-color-temporary-id
Resolves #39945
What?
This PR ensures that we have unique default color palette item names and slugs.
Why?
To prevent duplicates in the custom colors list.
How?
This PR increments the id based on the highest available id in the elements array.
The result is as follows:
Testing Instructions
Get comfortable.
+
symbol.Color ${n}
names, you could always seeColor 1
Note: while testing you might notice the following error:
This is because
CircularOptionPicker.Option
doesn't have unique keys when palettes have the same colors.I thought about preventing duplicate indices by concatenating the index in the PR, but I know that using indices as keys is discouraged. It's probably worth looking at in another PR where we could explore whether there is a more stable prop value we could use.