-
Notifications
You must be signed in to change notification settings - Fork 2
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
feat: allow options to assign many flags #3820
Conversation
Removed vultr server and associated DNS entries |
@@ -382,7 +374,74 @@ export const previewStore: StateCreator< | |||
|
|||
resultData(flagSet, overrides) { | |||
const { breadcrumbs, flow } = get(); | |||
return getResultData(breadcrumbs, flow, flagSet, overrides); |
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.
Decided to simplify this into a single function rather than this previous pattern of resultData
calling getResultData
- cleaning up another reduce
along the way 🧹 (we aren't even dealing with an array of anything in this method because a single flagset category is passed in, so reduce
was especially irrelevant in this case!! 🙈)
@@ -885,3 +871,43 @@ export const removeNodesDependentOnPassport = ( | |||
}, [] as string[]); | |||
return { removedNodeIds, breadcrumbsWithoutPassportData: newBreadcrumbs }; | |||
}; | |||
|
|||
const collectedFlagValuesByCategory = ( |
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.
No logical change here - this has simply been extracted out of autoAnswerableFlag
so we can re-use it in collectedFlags
and resultData
too
…ss/select-many-flags
count: gr.children.length, | ||
})), | ||
} | ||
categories: groupedOptions.map((gr) => ({ |
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.
nit: what do you think about changing these acronyms (gr
) to something a bit more meaningful?
I just find it slightly increases the mental load unnecessarily to read something that isn't immediately obvious (like I understood it was a group on second reading, but I think making code as frictionless and easy to read as possible is something to strive for!)
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.
Yep, agree here 👍
Another nice pattern can be to just destructure the keys we need.
I appreciate though that this is just a linting change and not something you've specifically touched so it can come as a follow up if needed.
categories: groupedOptions.map((gr) => ({ | |
categories: groupedOptions.map(({ title, children }) => ({ |
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.
Fully agree - updated now !
@@ -36,7 +46,7 @@ const Option: React.FC<any> = (props) => { | |||
imageAltText={props.data.text} | |||
/> | |||
)} | |||
<div className="band" style={{ background, color }}></div> | |||
{flags ? flags.map((flag) => <FlagBand key={`${props.id}-${flag.value}`} flag={flag} />) : <NoFlagBand />} |
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 clear component names 😍
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.
I know Daf said he would review this too but I felt nosy 😆 Looks good to me but obviously feel free to wait for his review as he probably has more context!
…ss/select-many-flags
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.
Working as expected, nice and clear to follow 👍
A few minor suggestions, no showstoppers.
On the whole flag/flags thing I think we can live with this as is for now (flag
pointing to an array) but it would be nice to handle a migration here for sure - it's nice simple use case as well.
One other comment would be on the validation - I think it's worth making the effort to enforce one per category just from the point of view of explaining this to users. I think it could be as simple as disabling the renderOption
if flag
from the same category is already in the group. We could also handle this in the validation schema. I'm aware that August flagged this as a blocker so happy for this to be a follow up here for sure 👍
count: gr.children.length, | ||
})), | ||
} | ||
categories: groupedOptions.map((gr) => ({ |
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.
Yep, agree here 👍
Another nice pattern can be to just destructure the keys we need.
I appreciate though that this is just a linting change and not something you've specifically touched so it can come as a follow up if needed.
categories: groupedOptions.map((gr) => ({ | |
categories: groupedOptions.map(({ title, children }) => ({ |
import { CustomCheckbox, SelectMultiple } from "ui/shared/SelectMultiple"; | ||
|
||
interface Props { | ||
value?: Array<Flag["value"]>; |
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.
Is this actually an optional prop?
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.
Annoying yes because Flag["value"]
is optional, despite it always be populated/required in practice. Will try to do a more thorough revisit of types as a followup 👍
const value: Flag[] | undefined = useMemo( | ||
() => | ||
initialFlagValues?.flatMap((initialFlagValue) => flatFlags.filter((flag) => flag.value === initialFlagValue)), | ||
[initialFlagValues, flatFlags], |
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.
I think that flatFlags
is a totally static value which won't change, so it can be removed from here.
@@ -28,7 +28,7 @@ export interface Option { | |||
id: string; | |||
data: { | |||
description?: string; | |||
flag?: string; | |||
flag?: Array<Flag["value"]>; |
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.
nit: Maybe a FlagValues
type could be nice?
Following on from #3764
Gist:
val
and singleflag
each - as we think about the future of automations & filtering, there's actually no reason a single Option shouldn't be able to support multiple flagsval
)Changes:
Option
node data typeflag
fromstring
toArray<Flag["value"]>
MultipleSelect
with grouping by category for editor "Option" modals within Questions & ChecklistsautoAnswerableFlag
for Filter node navigationgetResultData
/resultData
for Result node navigation and analytics trackingcollectedFlags
(no component or navigation dependencies)collectedFlags
in editor Console side panelOpen question:
** All of the above work with existing Option's
flag
(string
) and new/updated Option'sflag
(string[]
) without requiring a content migration of existing flow content (or all existing mock test data!).flag
toflags
and format legacy values as nice-to-have? (Might be good practice for clones?)