-
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: additional error messages for duplicate flow name and moving a flow #4244
Conversation
), | ||
); | ||
.catch(({ response }) => { | ||
const { data } = response; |
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.
Iterated on this a few times to get the cleanest code, I settled on this as it balanced explicit variable naming with concise lines of code in what is quite a long function
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.
Would appreciate feedback here, other iterations included a similar conditional check for when to display the 'Failed to move this flow.'
alert, but I am, as ever, treading lightly.
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.
This feels like clear, conditional error handling and meets requirements of more specific error messages I think 👍
(A frank question: would these few lines alone satisfy the original Trello ticket?)
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.
Yeah this alone would, the other error message changes were something I ran into myself, and thought it would be an easy change to add in. Do you think I should remove the other changes?
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.
Not at all asking you to remove the other changes, I agree it's ultimately a nicer user experience, just trying to gauge how requirements versus nice-to-haves were interpreted here.
It does seem like the additional prompt added more time, questions, and complexity, so it's important to be able to identify when & how we make decisions to prioritise additional "nice to haves" when reflecting on sprint tasks !
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.
Unique error messages are a definite improvement here!
A few initial comments & bugs - please try moving a flow to the valid team name "Barking & Dagenham" on the pizza 🐛
@@ -485,7 +490,8 @@ export const editorStore: StateCreator< | |||
send(ops); | |||
}, | |||
|
|||
moveFlow(flowId: string, teamSlug: string) { | |||
moveFlow(flowId: string, teamName: string, flowName: string) { | |||
const teamSlug = slugify(teamName); |
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.
Why is moveFlow
now accepting a teamName
rather than teamSlug
? How is slugify(teamName)
handling examples like "Barking & Dagenham", "Epsom & Ewell"?
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.
Assuming you've swapped teamSlug
to teamName
for the sake of error message formatting alone, I don't think it's a problem for the raw team slug to be in the error message (it's a very basic native alert still afterall!)
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.
Yeah I switched it so we could take in a teamName
so it can be shown in the error messages, which I got feedback on from Jonny, I had it like you suggested, but he did ask that we show the teamName
as its added. I did find it hard cause at one point you want to show the user that what they've entered isn't working, but then it obscures the fact we actually use the slug
for matching it.
On the Barking & Dagenham
one, this is interesting because the slug uses and
but the name uses &
- but when you slugify('Barking & Dagenham')
you get barking-dagenham
not barking-and-dagenham
. Has this been manually added in the database?
I tried the same thing in staging and I get the same error, so I don't think it's a bug I've introduced here? And I'm not sure how I'd resolve it, other than updating how we handle &
in the database slug
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.
This error does not exist on staging because staging prompts us for the slug ! I can successfully move a flow to B&G, which does not work on your pizza if I have to enter the team name and it gets automatically slugified
From memory, team slugs do not follow the automatic slugify convention because they need to be able to coform to/match council subdomains.
In my opinion, the prompt should still take a team slug, which editors can always find in the URL.
), | ||
); | ||
.catch(({ response }) => { | ||
const { data } = response; |
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.
This feels like clear, conditional error handling and meets requirements of more specific error messages I think 👍
(A frank question: would these few lines alone satisfy the original Trello ticket?)
if (newTeam) { | ||
if (slugify(newTeam) === teamSlug) { | ||
alert( | ||
`This flow already belongs to ${teamSlug}, skipping move`, | ||
); | ||
} else { | ||
handleMove(slugify(newTeam)); |
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.
As we chatted about, I removed the adding of teamName here and reverted it back to original state with slugify(teamName)
, but with flow.name
which seems harmless.
We should consider a future PR improving this error state though
editor.planx.uk/src/pages/Team.tsx
Outdated
@@ -233,14 +226,16 @@ const FlowItem: React.FC<FlowItemProps> = ({ | |||
{ | |||
label: "Move", | |||
onClick: () => { | |||
const newTeam = prompt("New team"); | |||
const newTeam = prompt( | |||
"Add the new team's slug. A slug is a way to represent a team name, for example 'Barking & Dagenham' would be 'barking-and-dagenham'. ", |
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.
Added more specificity here and using B&D as an example as it's probably the biggest source of error in this flow.
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: I would say "Enter the new team's slug. A slug is the URL name for a team, for example..." (then users know where to look to find theres!)
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.
Thanks for changes here ! All looks good and pizza behaving as expected
editor.planx.uk/src/pages/Team.tsx
Outdated
@@ -233,14 +226,16 @@ const FlowItem: React.FC<FlowItemProps> = ({ | |||
{ | |||
label: "Move", | |||
onClick: () => { | |||
const newTeam = prompt("New team"); | |||
const newTeam = prompt( | |||
"Add the new team's slug. A slug is a way to represent a team name, for example 'Barking & Dagenham' would be 'barking-and-dagenham'. ", |
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: I would say "Enter the new team's slug. A slug is the URL name for a team, for example..." (then users know where to look to find theres!)
return getUniqueFlow(updatedName, flows); | ||
} | ||
return { slug: newFlowSlug, name: name }; | ||
}; |
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.
This is much clearer ➕
@jessicamcinchak at the end of the day yesterday, Jonny said "destination" team sounds better than "new" team, since "new" might indicate they are making a new team. It seems a good switch to me and quite minor still, so I've implemented it. I'll mention it at Dev call to check your thoughts prior to merge |
@RODO94 my priority was reviewing/approving code here, Jonny's final wording suggestion is fine and there's no reason to wait to bring this to dev call in my opinion - let's please get this one merged so it's marked as "done" ahead of planning this afternoon ! |
Where does this PR come from?
This PR is linked to this Trello ticket: https://trello.com/c/Lsjy4ZgQ/3195-add-descriptive-error-message-for-duplicate-slug-when-copying-a-service-and-moving-it-to-a-new-team
It comes from a situation where a flow was copied and the user tried to move it to another team, but the other team already had a flow with the same name. No useful error was shown to point the user towards how to resolve it. This is what I have added here.
What has been added?
To guide users towards resolving errors themselves, I have added two new pathways / error messages.
This should help users tweak their initial trial to push it through.
uniqueness violation
error messages which points towards a slug duplication within a team.The struggle I had here was how to efficiently compare the slug name with that of the new team. This approach seemed the lightest without adding a new
getFlows()
with the new team ID, which could maybe be added at the api level or in the frontend, but this seemed to grow the boundaries of this task. I was also thinking of a future where we use the Dialog components we have created for user lists for services, changing the way users interact with these actions.