[Publisher] Add "Other" textbox to race breakdown

[nasaownsky]

Description of the change

Added "Other" textbox to race breakdown

Type of change

All pull requests must have at least one of the following labels applied (otherwise the PR will fail):

Label	Description
Type: Bug	non-breaking change that fixes an issue
Type: Feature	non-breaking change that adds functionality
Type: Breaking Change	fix or feature that would cause existing functionality to not work as expected
Type: Non-breaking refactor	change addresses some tech debt item or prepares for a later change, but does not change functionality
Type: Configuration Change	adjusts configuration to achieve some end related to functionality, development, performance, or security
Type: Dependency Upgrade	upgrades a project dependency - these changes are not included in release notes

Related issues

closes #1491

Checklists

Development

This box MUST be checked by the submitter prior to merging:

• Double- and triple-checked that there is no Personally Identifiable Information (PII) being mistakenly added in this pull request

These boxes should be checked by the submitter prior to merging:

• Tests have been written to cover the code changed/added as part of this pull request

Code review

These boxes should be checked by reviewers prior to merging:

• This pull request has a descriptive title and information useful to a reviewer
• This pull request has been moved out of a Draft state, has no "Work In Progress" label, and has assigned reviewers
• Potential security implications or infrastructural changes have been considered, if relevant

[nasaownsky]

Hi @mxosman! So after playing with this around, I think maybe injecting component into CheckboxOptions not the best idea? In this case we can place textbox either before checkbox or after it, and I personally think the before solution is better, because it will always be visible to the user. What do you think?

Also, how do you like my implementation of other_description into updatedDimensions? Let me know if it suits our needs for this!

And last one: I was thinking about displaying existing other_description in textbox, and noticed that if we selecting "Yes" in Are you able to record an individual’s ethnicity... section -- all of the Other Ethnicities are selected, and if selecting "No" -- only Other Unknown Ethnicity is selected. Am I understanding correctly that their other_description should be the same after all for all ethnicities?

[mxosman]

Hi @mxosman! So after playing with this around, I think maybe injecting component into CheckboxOptions not the best idea?

Ah, do you mind clarifying your thoughts on this? Is it moreso challenging to refactor the component to inject a text input? I could see us doing this more often - but just wanted to understand the challenges you ran into!

In this case we can place textbox either before checkbox or after it, and I personally think the before solution is better, because it will always be visible to the user. What do you think?

Hmm... the biggest thing I don't like about the textbox before is the big distance between 'Other' and the textbox - it makes it feel less intuitive what that input is connected to, despite the description in the box. Ideally, it makes the most sense from a UX perspective that it happens right after the 'Other' checkbox, but if that's too technically clunky, the next best option IMO is below the checkboxes because it keeps it within the closest proximity to the 'Other' checkbox. To help with it always being visible and to enhance its connection to the 'Other' checkbox, we could add a scrollTo reaction that scrolls to the bottom of the container when 'Other' is checked.

E.g. -

• Create a ref on the ScrollableInnerWrapper

       <Styled.ScrollableInnerWrapper ref={containerRef}>

• Move the isOtherChecked && (...input component) below the checkboxes

• Within the if (key === "Other") { conditional we can add the scroll behavior (using a setTimeout or implementing it via useEffect)

                setTimeout(() => {
                    if (containerRef.current) {
                      containerRef.current.scrollTo({
                        top: containerRef.current.scrollHeight,
                        behavior: "smooth",
                      });
                    }
                  }, 0);

Also, how do you like my implementation of other_description into updatedDimensions? Let me know if it suits our needs for this!

I think this works! It's hard to tell without the backend implemented b/c this is a complex component and the Other applies to 3 different sets of ethnicities, but reading the payload I think this works perfectly fine!

And last one: I was thinking about displaying existing other_description in textbox, and noticed that if we selecting "Yes" in Are you able to record an individual’s ethnicity... section -- all of the Other Ethnicities are selected, and if selecting "No" -- only Other Unknown Ethnicity is selected. Am I understanding correctly that their other_description should be the same after all for all ethnicities?

Ah, hmm... I might not be fully understanding - selecting an answer for Are you able to record an individual’s ethnicity... should not trigger any automatic selections I don't think, is that what's happening on your end? The only automatic selection that I know of is when you select No for that question and then check Hispanic or Latino - this auto selects the Unknown field.

[mxosman]

Let's adjust this to just be Please describe additional definition/clarification of the "Other" selection.

[mxosman]

Let me think about this section a bit more - I think it's right, but just want to make sure it's mapping to the correct Other/Ethnicity.

[mxosman]

OK - I took a closer look. This is almost there -- so basically there are 3 "Other" fields in the background of this feature:

1. "Other" race + "Unknown Ethnicity"
2. "Other" race + "Not Hispanic or Latino" ethnicity
3. "Other" race + "Hispanic or Latino" ethnicity

What gets updated should match the grid that's displayed in the UI. So, when a user is in the...

• "Unknown Ethnicity" state (they answered "No" for being able to record an individual's ethnicity, and "Hispanic Or Latino" is NOT selected) - then it should update the "Other / Unknown Ethnicity"
• "Hispanic or Latino" state (they answered "No" for being able to record an individual's ethnicity, and "Hispanic Or Latino" IS SELECTED) - then it should update the "Other / Not Hispanic or Latino"
• "Not Hispanic or Latino" state (they answered "Yes" for being able to record an individual's ethnicity) - then it should update all 3 - "Other / Unknown Ethnicity" AND "Other / Not Hispanic or Latino" AND "Other / Hispanic or Latino"

LMK if this is confusing (because it is) and I can give some more context as to why these fields work this way! But the TLDR is - the other_description should be set matching the blue dots in the UI depending on the state we're in if it's easier to think about it this way?

[mxosman]

Oh, one thing I realized I forgot to include in the ticket - can we make filling out the text field a requirement if a user is going to select "Other"? Meaning, if they enter nothing, we should keep "Other" unchecked. Sorry for the last minute complexity!

[nasaownsky]

Hi @mxosman! I've updated textbox logic according to your comments, so please check out my changes and if it's working correctly!

In the meantime I only have to find a way for this to work properly:

can we make filling out the text field a requirement if a user is going to select "Other"? Meaning, if they enter nothing, we should keep "Other" unchecked

Thank you!

[mxosman]

Thanks, @nasaownsky - will dive into this tomorrow morning!

[mxosman]

Nice @nasaownsky! It looks like it's working exactly as intended in all 3 cases I tested. Thank you for updating the logic + positioning of it and working through the last piece. Almost there! I'll review once everything is in place.