You are correct, filtering data on the backend is often better. Its always a tradeoff
- Filtering on backend: you load less data (if you filter do not change often), and can have better filter on your database. Cons: you will have to wait the response of your backend to display the info
- Filtering on frontend: you load all the data (which can be fine if your dataset is not too big). The filtering will be more “instant”. Cons: do not use if the data need to be secure or if your dataset is too big.
How to do it:
You will probably have a search input somewhere, with a corresponding internal variable available.
- You will then bind your collection query parameters to this variable. Depending on your backend this can be a query params or something else.
- You need to add a onChange workflow on your input, and fetch your collection here
Two warnings:
- On first load, your search variable will be null. You need to decide what filter/param you pass to your backend in this usecase. We often have customer with strange behavior at initialisation because of this (variable not defined)
- If you are using a text input for your search (and not a select of a checkbox), please use the search input and not a normal text input. The search input provide what we call a “debounce” value, so the “onChange” event is triggered only if the value does not change for a delay you can configure. If you use a normal input, your backend will be requested for each letter entered, which is not really performant
Hope it helps 