-
Notifications
You must be signed in to change notification settings - Fork 78
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
LF-4166 (4): Implement end to end animal creation flow #3397
LF-4166 (4): Implement end to end animal creation flow #3397
Conversation
cc1283e
to
5018ba8
Compare
* adjust storybook mock data
5018ba8
to
8d85441
Compare
animal_removal_reason_id: number | null; | ||
removal_explanation: string | null; | ||
removal_date: string | null; | ||
} | ||
|
||
export interface PostBatchSexDetail { | ||
animal_batch_sex_detail?: { sex_id: number; count: number }[]; |
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.
my only question is if this is to match up a name difference from frontend and backend -- is it possible to fix it to be one 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.
That's actually a bug...!!! Sex detail will not be added unless the key is sex_detail
.
Thank you so much for pointing that out!
…_animal_creation_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.
So treating this as the the last 🤞 ticket on add animals -- just pointing out everything I see. Approving in case we want to deal with them separately.
When I merge integration:
- animal use is not being filtered (eggs is viewable on pigs for example)
- summary screen is doing that awkward fullwidth thing where the sizes are not quite right and stuff is cut off on left and right.
- is there no snackbar when we successfully add animals?
@@ -89,7 +89,7 @@ export type Option = { | |||
[DetailsFields.USE]: ReactSelectOption<number>; | |||
[DetailsFields.TAG_COLOR]: ReactSelectOption<number>; | |||
[DetailsFields.TAG_TYPE]: ReactSelectOption<number>; | |||
[DetailsFields.ORGANIC_STATUS]: ReactSelectOption<number>; | |||
[DetailsFields.ORGANIC_STATUS]: ReactSelectOption<'Non-Organic' | 'Transitional' | 'Organic'>; |
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.
Could consider making 'Non-Organic' | 'Transitional' | 'Organic'
a reusable type -- its used twice here and would be useful for any locations that are going to be added like pasture.
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.
Definitely. I got a bit lazy about finding the right place for it, sorry. I'll make sure to add it!
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.
Thank you Duncan!
I think I can address the first two points. As the PR owner, I'm okay with making the changes in this PR or in a separate one, but as a reviewer, I prefer a separate PR. Please let me know if you guys have any preference!
Regarding the success snackbar, I assumed the summary screen would replace it. Let me confirm with Loïc!
@@ -89,7 +89,7 @@ export type Option = { | |||
[DetailsFields.USE]: ReactSelectOption<number>; | |||
[DetailsFields.TAG_COLOR]: ReactSelectOption<number>; | |||
[DetailsFields.TAG_TYPE]: ReactSelectOption<number>; | |||
[DetailsFields.ORGANIC_STATUS]: ReactSelectOption<number>; | |||
[DetailsFields.ORGANIC_STATUS]: ReactSelectOption<'Non-Organic' | 'Transitional' | 'Organic'>; |
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.
Definitely. I got a bit lazy about finding the right place for it, sorry. I'll make sure to add it!
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.
Wow, it feels so good when the full flow comes together in such a logical and readable PR -- I guess this was all the smart PR breaking up you did!!! ❤️
The only thing that makes me sad is how much you had to pass around broughtInId
! Did we mess up at some point architecting an id-based field as a radio? It kind of makes me want to do this:
// useAnimalOptions.ts
if (optionTypes.includes('origin')) {
options.originOptions = orgins.map(({ id, key }) => ({
value: { id, key },
label: t(`animal:ORIGIN.${key}`),
}));
}
And then update RadioGroup to accept it. But that's insane, right? 🤣 To give an object value to a radio?
It would make the component and utils so clean though 😂
// utils.ts
const isBroughtIn = data[DetailsFields.ORIGIN]?.key === 'BROUGHT_IN';
return {
birth_date: convertFormDate(data[DetailsFields.DATE_OF_BIRTH]),
origin_id: data[DetailsFields.ORIGIN]?.id,
Well, probably passing around a few more props to everything is better than violating the natural type of radios, isn't it?
Anyway the formatting functions are so tidy, I love them ❤️ Great job!
Co-authored-by: Joyce Yuki <[email protected]>
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.
Thank you Joyce for reviewing!
For the radio, using objects as values doesn't feel right, but maybe we could save an option itself as origin...? Let me try to clean up the code for broughtInId
!
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.
It's only optional about changing broughtInId
! I think the radio had annoyed me in the container/component too (the need for the getOriginEnum()
) so I had been thinking equally as well how sweet it would be to delete all of that as well in favour of being able to just
// Origins.tsx
watchedOrigin?.key === AnimalOrigins.BROUGHT_IN ? // ...
(I had also wondered if using broughtInId
could have simplified that component compared to the enum, but then figured altering the radios would be even shorter for both!)
I guess we could also construct a compound string of ${id}_${key}
too -- that could be a bit more of a compromise that keeps the radio value a primitive type.
I'm surprised to not know exactly which pattern is considered best practice for radios, though, whether we should be keeping the enum table separate from the ids and re-fetching like this, or something else 🤔💭
Anyway I do think any adjusts are optional, as the current pattern is clear and works well!
Edit:
but maybe we could save an option itself as origin...
Oh wait do you mean compound key values as well here? 😄
I wanted to address Duncan's inline comment, and I did it, but the last merge commit got the weird commit message somewhere... I want to amend the message, but I'll just leave it not to force push 😢 @kathyavini and I am not sure what the radio's best practice is either... let's revisit it later! |
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.
@SayakaOno oh I see, yes a wrapping-unwrapping seems a lot more sound but that does sound like a complicated refactor on Radio/RadioGroup! With the objects I just tested the value going all the way to <Radio />
and an alter on maybe key
and checked
?
But I'm really leaning towards compound string keys as being the most lightweight -- I'll open a demo PR after this one is merged to show what that looks like, and it will be fun to discuss with Anto what is best practice. No rush and probably when you get back then! 😄
(HAVE FUN!!!! 👋)
Thank you Joyce!! ❤️ I'm looking forward to finding good solutions!! |
Add animal fixes
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 doing this all! Looks amazing!
Going to address elsewhere but just to document that the bug existed at this point at least:
- On logout during addAnimals flow the logout redirect does not work as expected. The url stays as the add animals url and the litefarm top banner is the only thing present:
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.
Yay, into verification for Add Animals!! 🎉❤️
Description
onSave
function in AddAnimalsPostAnimalBatch
type and correct addAnimalBatches mutation request body typeJira link: https://lite-farm.atlassian.net/browse/LF-4166
Type of change
How Has This Been Tested?
Checklist: