Fetching data and filtering best practices

Hi weweb community!

I have a question, since it is better to filter data in backend, how can I filter them by a variable in a page?

For example, I have a search input in my page, I want to fetch only my search input value from the backend. Does putting a filter in the 'fetch collection" page in weweb does that or it filters in the frontend?

I think it would be more secure and faster if we only fetch what we need from the backend, is that correct? I need your input and help. Thank you.

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 :wink:

Hope it helps :slight_smile:

3 Likes

Sorry I don’t quite understan the binding to query parameters. If I add a filter at the fetch collections section, will it work the same? When I filter data in the collections page, does it fetch all the collection from backend or the filtered one only?

Thanks for mentioning this, @aurelie. I was just thinking about this functionality the other day.

To clarify, 1) Are you referring to the elements in the screenshot below?

Screen Shot 2022-08-16 at 9.00.56 AM

and 2) How would I set this up? I couldn’t find a debounce value in the component, so I imagine this workflow setup (below) would still be triggered for each letter entered.

Hi @caffeinatedwes,
a “Time delay” is very different from a debounce: time delay = will be executed with a delay, but all will be executed. Debounce = only the last value if no change during delay will be executed.

It is the “Search bar” element, but be carefull to select the search (which contain a text input). You can click on the small blue magnify icon, or use the navigator. Then you will see the delay, and will be able to connect to the onChange of it.

It will depends which data source you are using. Which one are you using?

Ahh, found it. Thank you!

Adding the screenshot and recapping for others.

To help others configure the desired functionality of not constantly calling the API with every character change, you would…

  1. configure the delay under the component’s specific settings and then
  2. set the workflow to trigger on the search bar with a “on change” trigger

That way, If you set the delay on the component to be, say, 1000 ms and constantly change the field (say every 300ms), your workflow would only run every 1000 seconds.

Correct me if I’m wrong, @aurelie :nerd_face:

Related, perhaps for @Joyce—it would be really cool to have the delay feature on other elements. For example, I’m currently building CRM-like functionality and there would be a notes section. It would be great to allow the user to take all the notes they want without having to worry about clicking “save” or “update record” by adding in a similar delay functionality to the “long answer” input.

1 Like

Debouced means = we wait 1000ms without any change before sending the event.
1000ms is a bit too long. An usual value for this is between 300ms and 600ms, so it will let the user typing and only request when he paused the typing for watching result.
It can indeed be very usefull for autosave feature (we have it inside weweb editor to have history and backend update by “batches” for example).
I let Joyce handle the product part :slight_smile: .

I think we can maybe do it with a bunch of JS, but that will not be really confortable. In the meantime using the “Search input” as a text field can work? If i remember correctly it is fully customizable as it contains a “normal” input.

2 Likes

Thank you, @aurelie! Really helpful insight regarding the length of time for the debounce configuration.

Some additional info for @Joyce if it’s helpful: using the search field like @aurelie describes might work for for use cases, but the main limitation is that it doesn’t support multiple lines, which eliminates many use cases.

Hi @aurelie, what if I want to use the debounce feature for say a number input, how can I do that? Maybe I can add some code to existing search input or number input. I need to enable users to update their data live( I use supabase) and update their backend after the delay. Also can you enable binding for the placeholder for the search input? That would also help my case, thank you