[cases] CaseScreen bugs

[arfamomin]

What's new in this PR

Description

• Change eligibility requirements to be darkGray and change to black when clicked
• Added updated warning icon
• Made entire StatusUpdatesBar clickable, cleaned up divs here too
• Also in StatusUpdatesBar, fixed alignment of the text
• Fixed? date issue being one day behind (need to check with Retool stuff)
• Added check in getStatusColor function that checks if string passed in is a valid status via StatusOptions const (array of all the colored status options enums); updated function keeps us from comparing strings directly

Screenshots

//: # 'Required for frontend changes, otherwise optional but strongly recommended. Add screenshots of expected behavior - GIFs if you're feeling fancy! Use the provided image template. Drag the desired image into the PR, then copy the link into the placeholder.'

This is me adding 'Action Required' temporarily into the GreenStatusOptions enum and it updates accordingly.

How to review

Order of files changed works, main stuff is in utils and types file

Next steps

Need to make sure date conversion works when realtime dates are added via Retool and that whole configuration.

Relevant Links

Online sources

Related PRs

CC: @ronniebeggs

[linear]

IMP-82 CaseScreen Bugs

[ronniebeggs]

Everything's looking good so far! Just a few comments to address. I don't know how to mitigate the button feedback while scrolling but I'll ask david in the meantime.

[ronniebeggs]

I think it'd be cleaner to make this full container a button by switching the View and TouchableOpacity components. That way the outer container becomes a button with the container styling, while the previous TouchableOpacity becomes a view with the updatesButton styling. Make sure to change the names though!

[arfamomin]

I ended up just removing the view div so all the styling for the button is in updatesButton and then textContainer and statusContainer define the styling for the content on the button.

[philipye314]

meow

[ronniebeggs]

Looks good! I tried standardizing shadow styling to apply across the app. Feel free to check how I did that. Please just fix the util function and it should be ready to merge!

[arfamomin]

Looked over how you standardized the shadow styling and double checked if there was anywhere else to apply it -- saw the update view when you click into a specific update had similar styling except the border radius was 15. I applied it to that in my latest commit but if it's bad practice to override one property, I can revert back to the previous commit.

[ronniebeggs]

Looked over how you standardized the shadow styling and double checked if there was anywhere else to apply it -- saw the update view when you click into a specific update had similar styling except the border radius was 15. I applied it to that in my latest commit but if it's bad practice to override one property, I can revert back to the previous commit.

Great catch! I don't think it's necessarily bad practice to override one property, it just comes down to preference. If we consider the alternative, we could remove the borderRadius prop from the global shadowBorder style, as border behavior differs slightly depending on which component it's applied to. But then perhaps in the future, if we decided to change the styling of these boxes, we'd have to think about how to change every component separately. TLDR it's probably fine how it is.