Makes sense. Also wanted to note that slice(0, -1) is what's used in the rest of the codebase, i.e., this change updates the only usages of slice() that don't already use the negative index syntax.

Thoughts on changing the title of the modal from "Select thread color" to "Thread color"?

I wonder if we want to close the settings dialog once the settings are saved? I think I'd prefer for it to be left open so I could make further changes if wanted.

Might be a better experience for the loading spinner to transition into a green button with a check mark and a message like "Settings saved." or something like that?

Looks good to me! Accepting, assuming the Test Plan was retried on the latest version of the script.

Had a git issue, final commit is here.

(It can be helpful to explain why you're adding me to a review if it's not obvious)

Overall logic looks good and makes sense, just some minor style fixes and should be ready to land!

Adding a minor comment about style, not sure about the rest of this revision because of lack of experience with this side of the codebase, so deferring to @atul on that. I'll investigate the backups aspect of the codebase further once he reviews it.

fixing git issue

Updated borderRadius style (now half of the height of the outer ring).

Updated borderRadius style (now half of the height of the outer ring).

Reverting prior commit's code changes, only addressing inline feedback from @ashoat (about 80 characters in comments/documentation) because the builds failed with the code changes. The log files indicated issues with pod, which is probably associated with my changes to the Podfile's code. This commit only modifies comments/documentation.

Address inline feedback. In addition to the lines @ashoat pointed out as being >80 characters, I noticed the rest of the file also had numerous lines that were >80 characters, so I fixed that too. Making all files have lines <= 80 characters long for the rest of the codebase is probably better suited to another diff since I'm assuming there are more files like this. Additionally, for the future, I suggest using a linter or something for shell scripts and configuration files (can be really simple, just to make sure overall style (like 80 character limit) is met).

Got it. I assumed we needed to memoize it since I was only looking at the dependency (threadInfo) but didn't realize threadNameInputDisabled only returns a boolean which is much less expensive to compute in this case.

Can we also make sure to lowercase the strings going into queuedChanges.color?

Here's the exact issue, it's actually not related to the #:

I think relying on us being consistent with hex values is a great idea, but we should still run the strings through tinycolor for the guarantee that color equality is handled the same way each time. For example, someone could easily forget to add or remove a # from the string but not know it, introducing a bug like this one. Using tinycolor.equals() removes this aspect of human error.

Moved conditional outside disabled prop and memoized the call to threadHasPermission so it's only called once the dependencies changed and not each time the Input is rendered.

Fixing git issue