Quality control & maintenance of SSWR

[marekdedic]

Let me start by saying thank you for creating SSWR, I know it's open source and you probably created it for free in your spare time, I'm very thankful for that. I also love the library, its ergonomics and pretty great docs. So thank you for that.

With that being sad, I feel like I encounter a lot of subtle issues every time I work with SSWR. Because doing SWR and async requests in general is quite tricky in my opinion, it's very difficult for me as a user to use SSWR when every time something doesn't work as I expected, I don't know if it is my issue, or if SSWR has a bug. To illustrate, in the ~year I have benn working with SSWR, I have encountered #24, #41, #42, #43 and #50.

So, what do we do about this? I propose starting with #51 and adding a test suite. Having a set of tests that reflect the expected behaviour and past issues can catch a lot of regressions, such as #50. I am willing to submit a PR adding some tests - with that in place, it would be easier to fix current issues and catch future ones.

Is that something you are ok with and willing to maintain going forward? I love this library, but honestly, I want something that works. There are some alternatives (tanstack query, svelte query, @svelte-drama/swr and possibly others), but if you plan on maintaining sswr into the future, I'd rather contribute here than switch to a lib I don't really like. On the other hand, I think it is fair game to say that your needs and interests have changed and you are no longer interested in maintaining SSWR - in that case, maybe somebody else will step up (I know it won't be me), or alternatively, the best thing would be to archive SSWR and point people to an alternative. But I don't know if that's the case - you seem to publish new versions quite frequently, yet at the same time some long standing issues like #24 remain unsolved...

None of this is meant in a bad way, I like the library, want it to succeed, I'm willing to contribute to that, but I'd like to know where it stands. Thanks!

[ConsoleTVs]

Heyo!

Thanks for the kind words and understanding beforehand!

I do get the frustration you feel, the svelte adapter has been something that I didn't have the time to manage. Overall, the underlying library doing the async work (swrev) was surpased by another library I built, simpler and more elgant, but sadly works a bit different, in a way that I suspect would be perhaps harder to implement in Svelte. Testing swrev was hard, and the new library I built (https://github.com/StudioLambda/TurboQuery) is 100% test covered, and this is sort of one of the pain points you mentioned, so I feel you!

I have adapters for Vue and Solid, but not for svelte sadly.

Anyway - I do feel the points here, but I do not have the capacity to maintain the library at a level that is acceptable at the moment. All I can offer you are two solutions:

1. Add you as a collaborator so that you could freely modify, push and tag / release new versions as needed to both, swrev and sswr.
2. Help designing and maintaining a Svelte adapter for TurboQuery. Given svelte now has signals, it might actually be easier that way.

My apologies for not having the library under an acceptable stability level...

[marekdedic]

Hi,
thanks for the honest response, I didn't know about TurboQuery.

Looking at npmtrends, it's pretty clear that sswr is the leading SWR solution for svelte (I added all the alternatives I could find). So from that point of view, it would be a shame to deprecate it, but probably a better option than leaving it unmaintained.

With that in mind, do you see it as feasible? I looked at the docs for TurboQuery and it seems to me to have a similar API to swrev, so it looks possible to migrate sswr to it without changing its interface too much. But I just skimmed it, you know much better. So I have 3 main questions

1. Is that feasible? I imagine it would be a new major version for sswr with some breaking changes, but ideally as few as possible.

2. When you're using TurboQuery, do you always need to provide a Event system? Or does TurboQuery come with some default one? I imagine one could be implemented with Svelte 5 runes and it would probably be the best choice in the long run, but I don't want to wait for Svelte 5. If it doesn't come with one, I think it could be implemented with Svelte 4 stores. What do you think?

3. I'd be willing to try to submit a PR for this, but longer term I don't want to take over the library. Would you be willing to maintain it if it were migrated to TurboQuery? (No is a perfectly good answer...)

Thanks!