Organizer page is now fetching from Sanity #21
Conversation
|
Deploy preview for hack-ics-uci-edu ready!
|
|
Deploy preview for hack-ics-uci-edu-sanity ready!
|
Switched the LinkedIn icons to the ones used on the current Hack site. |
| `*[_type == 'boardYear'][0]{corporate[]{person->{name, profilePic{asset->{url}}, socials[0]{link}}, position}, | ||
| logistics[]{person->{name, profilePic{asset->{url}}, socials[0]{link}}, position}, | ||
| marketing[]{person->{name, profilePic{asset->{url}}, socials[0]{link}}, position}, | ||
| tech[]{person->{name, profilePic{asset->{url}}, socials[0]{link}}, position}}` |
There was a problem hiding this comment.
This groq query can probably be condensed a bit.
Something like the following should work since we don't need the asset url anymore.
*[_type == 'boardYear'] | order(year desc) [0]{
corporate[]{
person->{
name,
profilePic,
socials[0] {link}
},
position
},
logistics[]{
person->{
name,
profilePic,
socials[0] {link}
},
position
},
marketing[]{
person->{
name,
profilePic,
socials[0] {link}
},
position
},
tech[]{
person->{
name,
profilePic,
socials[0] {link}
},
position
},
}
There was a problem hiding this comment.
Didn't catch this the first time around, but we probably shouldn't assume the LinkedIn link is the first one in the array. I'll come up with an updated groq query later and reply here.
| _type, | ||
| name, | ||
| profilePic, | ||
| socials[0] {link} |
There was a problem hiding this comment.
Replacing socials[0] with socials[platform == 'linkedin'][0] should ensure that we fetch the member's LinkedIn social.
This is essential filtering the socials array for a value where platform is 'linkedin', then selecting the first result that's found. It's not dissimilar from what we're doing on L35, where we're filtering then selecting the first result.
| person: Person, | ||
| position: z.string(), |
There was a problem hiding this comment.
Question: why is position separate from Person? Wouldn't it make more sense for position to be an attribute of the Person? Or is this to handle a person being part of multiple departments and be able to reuse a Person? Probably uncommon, but in such a case, someone might want different profile photos per department?
There was a problem hiding this comment.
This PR is focused on pulling content from Sanity, so the Zod schema here is just validating what's returned from Sanity.
As far as I can remember, we decided to separate the Person object from organizers to make it more reusable. For example, people may switch to different departments between years, or we may decided to use the Person object as an author field in the future. The profile photo was something we discussed at the time, but ultimately decided that it wasn't worth the extra complexity. Might be something we have to revisit in the future?
cc @samderanova
There was a problem hiding this comment.
Adding on to what Alex already mentioned, there might be former organizers that we might want to display on other sections of the site in the future (ex. alumni showcases). In situations like those, it would be better to just have one schema for all of our people and then use them in other schemas where needed instead of having two schemas to do the same.
| import linkedinLogo from "@/lib/common/assets/icons/linkedin.svg"; | ||
| import linkedinLogo from "@/lib/common/assets/linkedin-logo.svg"; |
There was a problem hiding this comment.
Chore: if we're replacing the logo icon, could we remove the older version.
There was a problem hiding this comment.
Issue: this asset seems quite large, is this official or made with a vectorizer? The color is also slightly off from the LinkedIn Blue. Would prefer to avoid diverging from brand guidelines.
A few notes