Infinite scroll
I want to make infinite scrolling on notifications page since this is notifications page I don't use SSR, What I have problems with is how observer sees the last element of array. When I have elements enough to show scrollbar it doesn't have problems since it doesn't intersect with last element so my fetch request doesn't run twice but if I have small amounts of elements it sees the last element so it makes another request
here is the code:
createEffect(() => {
if (observer) {
observer.disconnect();
}
const options = {
root: document.querySelector("#notificationsArea"),
rootMargin: "0px",
threshold: 1.0,
};
const callback = (entries) => {
entries.forEach((entry) => {
if (entry.isIntersecting) {
fetchData();
if (observer) {
observer.unobserve(entry.target);
}
}
});
};
observer = new IntersectionObserver(callback, options);
if (notifications().length) {
const newLastNotification = notifications()[notifications().length - 1];
if (lastNotification && newLastNotification.id !== lastNotification.id) {
lastNotification.id = newLastNotification.id;
lastNotification.created_at = newLastNotification.created_at;
const target = document.querySelector(#${CSS.escape(lastNotification.id)});
if (target) {
observer.observe(target);
}
}
} else {
fetchData()
}
});
fetchData is an async function that makes request to api and runs setNotifications(prev => [...prev, ...newData])
I thought of counting all the rows in postgresql so then I would probably check if the last element should be observed or not by observer API so it won't no longer make 2 requests.13 Replies
First time doing infinite scrolling so I am kind of lost here
i think your last point might be a good idea no?
Well now I think I won't really have that much rows in notifications table so the cost of counting rows won't be that demanding, well I am concerned of performance mostly
if you know the total items and you know that the items might now increase while your last page is visible( which i think is your case, as notifications are prepended to the list and not appended)
then a check if you are on the last page / record
can be used to guard against the double fetch.
however this will depend how you actually fetch each page
if you use normal pagination, and data changes things may get offseted
I use cursor based pagination by tracking created_at and id of last notification then I compare (created_at, id) <|> (last_element_created_at, last_element_id)
ok that is good, cursor based is what I was thinking
technically you can just use ids get me N from last id
if ids are auto incremented
potentially, in the back you can try fetching the next page without returning it
if there are items, you then indicate that in a flag in the response
Exactly that was my first thought
Yeah another one I want to ask if you don't mind so how would you approach SSR here? I thought I would have say:
const notifs = createAsync(fetch)
const [otherNotifications, setOtherNotifications] = createSignal([])
after this initial request I would add "createEffect" and track the last id/created_at for "notifs"
But right after user scrolls and makes request with "createEffect"
I will render it using <For each={[...notifs, ...otherNotifications()]}>{renderLogic}</For>
Would this be any faster?
I am not sure how is the state in the application while ssr is involved
but if you have the
hasMore available
then your observer logic will know if you need to fetch or not
correct me if I am wrong
is the question how to make the hasMore available to the observer on first load?Well if I'll have
hasMore I will change notifcations to object instead of array and have
const [notifications, setNotifications] = createSignal({hasMore: true|false, notifications: []})
The observer will probably be stopped from fetching on page refresh since I already have onMount doing initial request
so here I would have smth like
createEffect(() => {
if (!notifications() || notifications().length === 0 && !loading() && !notifications().hasMore) return;
My question is when we try to have SSR how do I keep track of 2 different signals basically to then render would this be correct approach? <For each={[...notifs, ...otherNotifications()]}>{renderLogic}</For>1. yes, you will need to keep the hasMore somewhere
because you will need to update it after every fetch
you can probably keep it in the signal( coupled with the notifications), but may be a store will be more appropriate for better granularity .
I can't really answer ssr specific questions I am not too familiar with how it works in solid
however
instead of this you probably want just
notifications()
which can be a memo. or a store you update
which will have all the notifications loaded thus far.
so when the observer trigger a fetch, the fetch update the notifications
which will update the render.Thanks for responses I think just having
hasMore should help.yeah try that see how it goes, if you have more problems just ask again
Alright I'll update you soon, I think I will try having SSR as well just for performance purposes
Thanks for help It works fine I have SSR now on initial load and then observer fetches on scroll.