Refactoring search queries in Adonis.js
Published 4/25/2019
In a previous post we were looking at various ways to keep controllers in Adonis small, but the various ways were not helping us with the following:
const Post = use('App/Models/Post')
class PostsController {
async index({ response, request }) {
const query = Post.query()
if (request.input('category_id')) {
query.where('category_id', request.input('category_id'))
}
let keyword = request.input('keyword')
if (keyword) {
keyword = `%${decodeURIComponent(keyword)}%`
query
.where('title', 'like', keyword)
.orWhere('description', 'like', keyword)
}
const tags = request.input('tags')
if (tags) {
query.whereIn('tags', tags)
}
const posts = await query.where('active', true).fetch()
return response.json({ posts: posts.toJSON() })
}
}
So let's dive into various ways we can clean this up.
Scopes
Adonis has a feature called query scopes that allows us to extract query constraints. Let's try this with the keyword constraint.
keyword = `%${decodeURIComponent(keyword)}%`
query
.where('title', 'like', keyword)
.orWhere('description', 'like', keyword)
To create a new scope we would go into our Posts
model and add the following method to the class
static scopeByEncodedKeyword(query, keyword) {
keyword = `%${decodeURIComponent(keyword)}%`
return query
.where('title', 'like', keyword)
.orWhere('description', 'like', keyword)
}
Now back in the controller, we can simply write
if (keyword) {
query.byEncodedKeyword(keyword)
}
It's important that the method name is prefixed with scope
. When calling scopes, drop the scope
keyword and call the method in camelCase (ByEncodedKeyword
=> byEncodedKeyword
).
This is a great way to simplify queries and hide complexity! It also makes query constraints reusable.
Check out my e-book!
Let's talk about these conditionals...
I actually created two traits to overcome all these conditionals. If you are new to traits please check out in the repositories on how to set them up.
Optional
Repository: https://github.com/MZanggl/adonis-lucid-optional-queries
With Optional we will be able to turn the index
method into
async index({ response, request }) {
const posts = await Post.query()
.optional(query => query
.where('category_id', request.input('category_id'))
.byEncodedKeyword(request.input('keyword'))
.whereIn('tags', request.input('tags'))
)
.where('active', true)
.fetch()
return response.json({ posts: posts.toJSON() })
}
We were able to get rid of all the conditionals throughout the controller by wrapping optional queries in the higher order function optional
. The higher order function traps the query object in an ES6 proxy that checks if the passed arguments are truthy. Only then will it add the constraint to the query.
When
Repository: https://github.com/MZanggl/adonis-lucid-when
The second trait I wrote implements Laravel's when
method as a trait. Optional
has the drawback that you can only check for truthy values, sometimes you might also want to check if an input is a certain value before you apply the constraint. With when
we can turn the search method into
async index({ response, request }) {
const posts = await Post.query()
.when(request.input('category_id'), (q, value) => q.where('category_id', value))
.when(request.input('keyword'), (q, value) => q.byEncodedKeyword(value))
.when(request.input('sort') === 1, q => q.orderBy('id', 'DESC'))
.where('active', true)
.fetch()
return response.json({ posts: posts.toJSON() })
}
When
works similar to Optional
in that it only applies the callback when the first argument is truthy. You can even add a third parameter to apply a default value in case the first argument is not truthy.
Of course we can also combine these two traits
async index({ response, request }) {
const posts = await Post.query()
.optional(query => query
.where('category_id', request.input('category_id'))
.byEncodedKeyword(request.input('keyword'))
.whereIn('tags', request.input('tags'))
)
.when(request.input('sort') === 1, q => q.orderBy('id', 'DESC'))
.where('active', true)
.fetch()
return response.json({ posts: posts.toJSON() })
}
An even more elegant way would be to use filters. Check out this module.
We could turn our controller into
const Post = use('App/Models/Post')
class PostsController {
async index({ response, request }) {
const posts = await Post.query()
.filter(request.all())
.fetch()
return response.json({ posts: posts.toJSON() })
}
}
This has the benefit that it removes all constraints from the controller, but also the drawback that it is not 100% clear what is happening without a close look to all the filters you created.
Conclusion
There's always more than one way to skin a cat, we could have also extracted the queries and conditions into a separate class specifically for searching this table (kind of like a repository pattern but for searching).
I hope this post gave you some ideas on how to clean up your search queries.