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
I86 search by pet names in contacts page #88
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Hi team, just a note - 9/10 clients will only have one pet. So it's probably not necessary to normalise pet(s) into separate entities with independent notes - per what I've seen in one of the PR previews below :) Only loosely related to this PR, but has implications for ease of display/searching - so just the heads up! Cheers, Dave. |
Hi Dave, I've fixed the pet section. |
Hi Dave, We initially had pets separated so that the user could choose which specific pet they were doing a visit for as well as selecting the specific pet for incident/vet reports. However, we would be happy to go with the way you've suggested, making the user select the client(s) and inputting the specific pet(s). Vet/Incident reports would operate the same way, with the user manually inputting the pet's name. |
Understood, but no need to double enter - a vollie visiting a client with 2
dogs would be walking both at the same time.
And if there's a vet report or incident that happens to only apply to one
of two pets, they can just specify in the associated report notes. These
will always be followed up by a phone call anyway 👍
Cheers, Dave
…On Mon, 18 July 2022, 10:39 pm Jun, ***@***.***> wrote:
Hi team, just a note - 9/10 clients will only have one pet. As such,
suggest "Pet(s)" really only needs to be a single text box - e.g. "Fido" or
"Frank & Ginger". e.g. you can see that we capture the source data as a
single "Name(s)" field at https://www.poopswa.org.au/client-application/ [image:
image]
<https://user-images.githubusercontent.com/6415842/179434307-4c954746-6839-40c3-9b73-6bdb7919c2f7.png>
So it's probably not necessary to normalise pet(s) into separate entities
with independent notes - per what I've seen in one of the PR previews below
:)
Only loosely related to this PR, but has implications for ease of
display/searching - so just the heads up!
Cheers, Dave.
[image: image]
<https://user-images.githubusercontent.com/6415842/179434042-f061fde7-f74b-489e-9c97-1845c13b194e.png>
Hi Dave,
We initially had pets separated so that the user could choose which
specific pet they were doing a visit for as well as selecting the specific
pet for incident/vet reports.
However, we would be happy to go with the way you've suggested, making the
user select the client(s) and inputting the specific pet(s). Vet/Incident
reports would operate the same way, with the user manually inputting the
pet's name.
—
Reply to this email directly, view it on GitHub
<#88 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABQ6LYXMPE46XQOEF7FKMQLVUVUDZANCNFSM532BGHKQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
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.
Overall looks really good. A few suggestions:
- Search bar currently searches in the middle of words too, might be better to only pattern match from the beginning of words (this might be a big task so maybe merge this PR before tackling this if you choose to)?
- Convention is to use PascalCase for component file names (e.g. SearchTag.tsx rather than searchtag.tsx)
- searchbar.tsx could be renamed to index.tsx if the SearchBar folder represents that component
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.
looks good
Change Summary
Related Issue