Replies: 1 comment
-
|
The clean workaround is to stop passing filters around as objects and pass around functions that apply filters to the query builder. For example: type PostQuery = ReturnType<typeof queryCollection>
type Filter = (query: PostQuery) => PostQuery
const byAuthor = (author: string): Filter => (query) =>
query.where('author', '=', author)
const byTag = (tag: string): Filter => (query) =>
query.where('tags', 'LIKE', `%${tag}%`)
export function applyFilters(query: PostQuery, filters: Filter[]) {
return filters.reduce((q, filter) => filter(q), query)
}Then your shared list code can stay generic: let query = queryCollection(event, 'blog')
query = applyFilters(query, filters)
const posts = await query.order('date', 'DESC').all()That keeps the abstraction you had before, but the reusable unit is now query transformation rather than where object. It also composes better when one page needs multiple conditions. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hello,
In my blog I had an abstract PostList component allowing me to reuse it on multiple pages with different filters.
I did that by isolating the logic into a separate helper composable and passing the specific filter object in, depending on the usage
But now with the new syntax, the where clause requires three separate params, so you cannot encapsulate the filter into an object anymore like before
Will there be another approach in the future, and what was the reason behind ditching it in favor of the new one?
Beta Was this translation helpful? Give feedback.
All reactions