Skip to content
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

refactor: Simplify/cleanup officer data approach #37

Merged
merged 3 commits into from
Dec 13, 2023

Conversation

WillBAnders
Copy link
Member

PR split from #35 for review. This has a few changes; may be worth looking at specific commits.

  • OfficerData has been cleaned up and duplicate entries removed (there was both officerData and the older officerCardData). In general, the approach here is that officerData contains personal information about an officer. Information about positions is only present as part of positionData later on, which references the corresponding officer in officerData. This is the primary improvement in this PR.
    • This was the original intent with having both a separation of concerns - effectively, abstracting the shared (officer) information about positions into it's own constant that can be reused.
    • Note that there is a now a new OfficerData type which is used by OfficerCardProps rather than using OfficerCardProps directly - in general, types for data should be kept separate from any component prop types. This also helps avoids circular dependencies.
  • The socialLinksData field has been replaced by socials (just a slightly nicer name) that is map of site to url. This greatly simplifies the amount of data that needs to be stored for each officer, as the icon image path can be looked up separately.
  • Minor key attribute improvements while here.

export const positionData: {
[key: string]: { [key: string]: OfficerCardProps };
} = {
export const positionData: Record<string, Record<string, OfficerData>> = {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Comment]: This is actually an interesting case - above I changed socials to be an map instead of an array, here I probably would have gone in the other direction. Having positions be a map feels a little weirder to me; in part because there's not really any mapping to look up values here - rather it fully relies on iteration order. I think the fact that the keys have spaces too certainly doesn't help this.

Either way; let's leave this as is - any change is a style preference and doesn't have any additional benefit/savings right now.

@Phantom0110
Copy link
Contributor

Phantom0110 commented Dec 13, 2023

Wow, that looks a lot cleaner. Really helped remove a lot of unnecessary long repeats of code. I was confused about the difference between officerCardData and officerData so that helps clear things up. Awesome work!

@WillBAnders WillBAnders merged commit 3e46aee into feature/past-officers Dec 13, 2023
1 check passed
@WillBAnders WillBAnders deleted the refactor/officer-data-approach branch December 13, 2023 20:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants