Generate standings table automatically #32
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Replaces the manual process of updating the standings table in the contentful post with a custom contentful entry that will be replaced with a table that fetches the standings from supabase. Includes several changes to make this work: - Setup the supabase client - Create an API route to fetch the standings for a given week range - Create a contentful entry for the standings that is replaced by html - Ideally we could use a svelte component to replace this instead of raw html but one thing at a time Also did some rearranging of the various models and utils to hopefully allow us to scale our file structure better. And switched to pnpm.
tuckergordon
force-pushed
the
standings-api
branch
from
a3ee19b to
ae7ceae
Compare
tuckergordon
force-pushed
the
standings-api
branch
from
d44d0ab to
99f3eef
Compare
pnpm was having issues that npm wasn't, so reverting for now Uninstall supabase cli rm package-lock
tuckergordon
force-pushed
the
standings-api
branch
from
10a3ba3 to
1dd0168
Compare
tuckergordon
force-pushed
the
standings-api
branch
from
46be0e2 to
41c5a58
Compare
joe-seibert
left a comment
joe-seibert
left a comment
There was a problem hiding this comment.
I think everything here looks fine, so marking as approved. I left a couple comments that are much more about best practices/stylistic stuff when it comes to queries, particularly revolving around team_id. If there's anything else specifically you'd like me to take a look at, let me know, but otherwise this looks good to me.
| points_for: points_for.sum(), | ||
| points_against: points_against.sum(), | ||
| max_points_for: max_points_for.sum(), | ||
| teams:team_id(id, name) |
There was a problem hiding this comment.
Similarly, you shouldn't need to do teams:team_id(id, name) here. I think it's suitable to do teams!inner(name). This will give you just the team names, which is what you should be caring about for generating the standings in the post, and the !inner just makes sure the query doesn't return a bunch of NULL results.
|
|
||
| return { | ||
| teamId: standing.team_id, | ||
| // @ts-expect-error - teams is not typed correctly yet |
There was a problem hiding this comment.
Still true? I am not sure I know how to help with this, maybe it's just something you're already expecting...
| return data | ||
| .map((standing) => { | ||
| const wins = standing.win_h2h + standing.win_median; | ||
| const losses = totalWeeks * 2 - wins; |
There was a problem hiding this comment.
This is...probably fine. It seems pretty foolproof, though there are other ways to get this directly from the queries if you'd like. I think either way is roundabout, though, and this minimizes the number of queries you need to make, so it's probably fine.
There was a problem hiding this comment.
What do you have in mind?
Remove unused teamId and shorten query
Replaces the manual process of updating the standings table in the contentful post with a custom contentful entry that will be replaced with a table that fetches the standings from supabase.
Includes several changes to make this work:
Also did some rearranging of the various models and utils to hopefully allow us to scale our file structure better, plus updated everything to use pnpm.
Adding standings to posts
So instead of having to manually type out the standings in the contentful post, now you basically add a placeholder that is a custom entry. Here's how it looks
1. Add a new embedded entry to the post
2. Select the
standingsmmish componentThis is a little weird so let me explain. In Contentful you can create custom content types. I have created a
mmish componentcontent type that takes one parameter: the name of the component (e.g.standings, or in the future we'll usematchupsandlotterytoo). Each one of these is "published" as an entry and then can be used.I originally was thinking about making each of them they're own content type and then allowing optional parameters to be passed in (e.g. maybe you pass the week parameter into the standings content type), but that would require us publishing a new entry for every different parameter configuration. Maybe that could work, but since all i really care about is the name of the custom component to add, i figured it would be easier to keep it generic.
3. Then the entry should appear in your post!
On the back-end, the JS code looks for mmish components with name
standings. If it sees one, it swaps it out for a standings table that is fed from the database (it uses the week number in the slug to figure out what week it is)