N
Novu9mo ago
sandsower

headless fetchNotifications() overfetches on multiple calls

I'm using the headless library to power a component that has 2 states, all notifications and unread only. It all works fine on initial load but if I change the state (and make another call to fetchNotifications) then there seems to be a feedback loop where the data gets fetched for both cases multiple times. I've tried unsubscribing after receiving a notifications response which does stop the refetching but then I can no longer listen for unseen notifications. NOTE: The example on the novu-headless-demo has an await for the fetchNotification call but fetchNotification returns no promise so it doesn't quite work 1:1, no idea if this is related
5 Replies
Ask Inkeep
Ask Inkeep9mo ago
Hi @sandsower, I'm an AI assistant for Novu. While a team member reviews this question, I'll look through relevant sources and see if I can provide suggestions. Please tag @Ask Inkeep with any follow-up questions. ----------------------------- While I generate an answer, here are some sources that might be helpful: * Headless API Reference * Overview * Preferences * Python ----------------------------- Answer Your description suggests a potential issue with managing state and event listeners effectively within the headless library usage. If changing states triggers multiple fetchNotifications calls leading to a feedback loop, it likely involves how these state changes are managed and how listeners are set up or removed. Regarding the fetchNotifications method not returning a promise, it's designed to work with callbacks rather than promises. This design choice means that using await directly with fetchNotifications won't work as expected because it doesn't return a promise. Instead, it expects a listener function where you can handle the fetched data. The headless library allows for a more granular control over fetching and managing notifications. When changing states (e.g., from all notifications to unread only), ensure that: 1. Any existing listeners are properly removed or managed to prevent them from triggering unwanted fetchNotifications calls. 2. State changes that trigger fetchNotifications calls are debounced or controlled to avoid rapid, repeated calls that could lead to the feedback loop you're experiencing. If unsubscribing stops the refetching but prevents listening for unseen notifications, it could be that the unsubscribing process is too aggressive, removing more than just the fetch-related listeners. You might need to separate the concerns of fetching notifications and listening for unseen notifications more explicitly in your implementation. To address these challenges: - Ensure that you manage listeners and state changes carefully. It might help to have a centralized state management mechanism that controls when and how often fetchNotifications is called based on user actions or state changes. - Consider managing the subscription to unseen notifications separately from fetching notifications, so unsubscribing from one doesn
Ask Inkeep
Ask Inkeep9mo ago
't affect the other. - Review your implementation for any unintended repeated calls to fetchNotifications and ensure that any event listeners added are also properly removed when no longer needed or when the component unmounts. For more detailed guidance or if this doesn't address your issue fully, reviewing the official Novu Headless API documentation (1) and seeking assistance from the Novu community or support channels might provide more tailored solutions to your specific implementation challenges.
Ask Inkeep
Ask Inkeep9mo ago
Got it. Tagging @Support for additional help.
Pawan Jain
Pawan Jain9mo ago
@sandsower could you please share the code snippet?
sandsower
sandsowerOP9mo ago
I've actually managed to solve it, my misunderstanding was that each call to fetchNotifications opened up a new listener when I thought the previous one would automatically close. I'm now just handling the unread only option with a simple filter after the initial fetch.
Want results from more Discord servers?
Add your server