feat(multi-tags): add filtering to collections #916
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Datadog ReportBranch report: ✅ 0 Failed, 232 Passed, 36 Skipped, 38.29s Total Time 🔻 Code Coverage Decreases vs Default Branch (1)
|
seaerchin
force-pushed
the
feat/collection-filters
branch
from
9b0309d to
75f68d6
Compare
| @@ -3,6 +3,8 @@ import type { IsomerSiteProps, LinkComponentType } from "~/types" | |||
|
|
|||
| export interface Tag { | |||
| label: string | |||
| category: string | |||
| values: string[] | |||
There was a problem hiding this comment.
actually for starters, we discussed that the entire universe of values allowed we will only know at build time till we achieve studio compatibility
This is because the tags are stored on an collection-item level
Is that still the case?
There was a problem hiding this comment.
yea, this is taken at build time. you can see this at publishing/index.ts where we write the tag to the sitemap
There was a problem hiding this comment.
sorry not sure if im understanding correctly, but why do we need both selected and values? seems to me that
selectedis a subset ofvalues- and since total possible tag values are computed on build time, then we don't really need
values, but we can just do a "concat + uniq" of allselected?
There was a problem hiding this comment.
Hmm yea, similar thoughts. I didn't think we will need the values array here. In the long term, this will be moved to the collection level when it will be required.
However, for current implementation, values will not be known till build time
There was a problem hiding this comment.
correct me if im wrong, but will not knowing the values till build time be an issue?
seems like we only require all values for the filters and options, which is fine to only be known during build time
There was a problem hiding this comment.
yea, you're right - i thought we were gonna ask the users for the set of values then display them in the filters (eg: a: 0) but actually we'll hide those wtihout any matches so i'll remove this
There was a problem hiding this comment.
@adriangohjw - not sure i understand your question! i think we don't require the values at all - i think, for now, we can just fetch all values from db (collections are 1 level deep), which shuold still be manageable
seaerchin
changed the base branch from
feat/collection-tags
to
graphite-base/916
seaerchin
force-pushed
the
feat/collection-filters
branch
from
972af8c to
ffc95fa
Compare
Problem
This PR adds filtering to collections through the use of tags.
Solution
Tagsto the schema onCollectionPagePageSchemaPAGE_RESOURCE_TYPE, which means that even though the schema can only expose it on page items. we might want to expose it on files, which would necessitate a slight change inhow we generate hteSitemapEntries. not too sure if this is what we want, so i omitted it for now. need to think abit more herepublishing/index.tsso that it gets written to the sitemap entry (and hence, to disk)Collection, extract thetagsfrom theSitemap. add filtering logic onto our collection so that it will display the correct cards on filter click. take note that the logic here can be (and should be) reused for collection but not for years due to how the comparison is madeitem.categoryand notitem.tagsVideos
Screen.Recording.2024-12-03.at.10.40.57.PM.mov