Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support background refresh #24

Open
Tbhesswebber opened this issue Feb 18, 2024 · 2 comments
Open

Support background refresh #24

Tbhesswebber opened this issue Feb 18, 2024 · 2 comments

Comments

@Tbhesswebber
Copy link

Being able to configure background refresh within loaders would be incredibly valuable. Currently, I'd need to add side-effects and manage them along with abort controllers on my own, but that should be a pretty standard pattern across each loader.

In thinking about how I would want to leverage this, I realized it may be nice to pass functions to an optional triggers property, which would then allow users to do things like avoid refreshes in idle states, explicitly refresh when a window gains focus or certain requests are made, etc.

I'm more than happy to tackle this, but I think it would be valuable to discuss what the ideal interface would be before really diving in.

@mariusandra
Copy link
Member

Hey, indeed, background loading and cancellation are patterns I've also had to implement a few times. A common approach could definitely speed things up, yet I don't have many opinions on what that should look like. At work we have a saying "PRs over issues", so just implement something, and that'll make it easier to discuss the next steps.

Then, we could implement this directly into loaders, or make a separate abortableLoaders plugin. I'd actually suggest making a separate plugin. This keeps the core loaders logic simple, and gives you a lot of flexibility in making it work the way you want.

As for other tips, personally I've always put the AbortController into the logic's mutable cache object, and poked it upon request, and with the abort actions. This seemed to work well. However I definitely wouldn't have minded if the framework too care of this for me.

Good luck and hope this helps somewhat! Also apologies for the delay on my side. I'm happy to discuss this further, and with a smaller delay this time (I'm on 2 weeks of holiday now, so I finally got the time 😅)

@Tbhesswebber
Copy link
Author

Tbhesswebber commented Apr 1, 2024

Awesome, thanks! I totally agree with PRs over issues (and usually create an issue and a PR at the same time in OSS repos so that I can reference one from the other), but I often have a hard time with that when I know so little about the intended direction of a project. Haha

I appreciate the tips on how you've solved it and will dig deeper and see what I come up with. I'll create a rough solution and link the repo here so we can discuss. Something to think about in the meantime - would you want something this "core" to how we build for the web to live within the keajs GitHub org once it's at a stable point and should the docs live in the Kea docs or standalone?

Have a great holiday!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants