@timgl we worked together on this at the offsite to try to avoid the situation where the request in loadSessions is called twice or even three times due to various things updating the URL, state, etc.

I now came upon an extremely simple solution that would solve all problems without any of the hacks we implemented:

export const sessionsTableLogic = kea<sessionsTableLogicType<Moment, SessionType>>({
    loaders: ({ actions, values, props }) => ({
        sessions: {
            __default: [] as SessionType[],
            loadSessions: async (_: any, breakpoint) => {
                const { selectedDateURLparam } = values
                const params = toParams({
                    date_from: selectedDateURLparam,
                    date_to: selectedDateURLparam,
                    offset: 0,
                    distinct_id: props.personIds ? props.personIds[0] : '',
                    properties: values.filters,
                })
                // add this!
                await breakpoint(10)

                const response = await api.get(`api/insight/session/?${params}`)
                breakpoint()
                if (response.offset) {
                    actions.setNextOffset(response.offset)
                }
                return response.result
            },
        },
    }) 
)}

Adding a simple breakpoint before the api.get debounces the query and if another loadSesssions is called within 10ms since the first one, no call is made. This is a simple and cool debouncing pattern that's super easy to implement with kea loaders. The number could even be smaller, since all the actions fire right after each other.

Not saying it's needed to redo this PR, but something to definitely keep in mind for the future :).

@macobo @mariusandra Thanks both. Marius, I've implemented your suggestion which made things a lot easier. I'm now also using PropertyFilter's built in urlToAction which means back and forward history navigation works too!

Great! One comment (nit, feel free to ignore) coming back to what Karl said. It might be a good idea to replace all those filter types Record<string, any>s with some PropertyFilterType from src/types, even if for now it's just:

export type PropertyFilterType = Record<string, any>

It can be converted into a real type some time later. This will however already help future refactors.

Fixed! Also cleaned up filters/properties confusion