v5.0.0

V5 🔥

A complete rewrite of solid-swr mostly focused on performance

Real performance difference from v4

So I migrated my production app to v5 and here is the comparison

Before

After

How?

Basically v0-v4 were never fast anyway as every hook instance had to copy the cache

https://github.com/Tronikelis/solid-swr/blob/424e295a8c8fde642be95370cf96fed04517ee49/src/lib/index.ts#L81-L85

See the structuredClone, because of this when using useSWR intensively you will incur a lot of GC time which is not necessary

Plus notice the dequal call, this is a kinda patchy workaround to not clone everything everywhere, but only when actually needed, but dequal itself is expensive to call

V5 now has 0 dependencies and is about 1.5kb

Breaking changes

I recommend reading v5 readme as I've written everything there

There are a ton of breaking changes in this release, but that is necessary to make this library as I envision it to be

Store / Cache

Now solid-swr manages its own store, but you can hook into it and remove items at will (lru is provided with relevant hooks), more info in v5 readme

So isLoading, data, err is now in a single solid store for all keys

Core / Extra

Now hooks are separated into /core and /extra, all /extra hooks are created with using the /core hooks, that is you could have created all the /extra hooks yourself easily

So there now are 2 swr options SwrOpts and SwrFullOpts to completely separate core from extra, the latter is from extra

Prefer composition

In previous versions I just wrote everything in one function which was difficult to maintain and extend,
now in core you will find:

• createRevalidator
• createMutator
• useSwr <- a "pure" minimal swr

These utils are the corner stone of everything, every /extra utils is using them

No more custom window events

Custom window events are removed, now solid itself manages syncing of the data, however this has some implications

For example, in v4 when you mutate, you send the event to the hooks which gets their options from where they were called,

in v5, when you mutate, the function itself changes the state, thus it can get incorrect options, that's why I recommend always passing in options when creating revalidators or mutators, or abstract this away somehow

useSwrMutation is removed

Although you can still easily in 30 lines create it yourself, I don't believe it is the right abstraction, as it gets confusing when you call update.revalidate() or update.populateCache, but you are actually changing some arbitrary keys

What's Changed

• v5 by @tronikelis in #61

Full Changelog: v4.1.0...v5.0.0