Releases: tronikelis/solid-swr
v5.0.2
v5.0.1
Only type changes, when producing with a mutator, the previous data can be undefined
Full Changelog: v5.0.0...v5.0.1
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
How?
Basically v0-v4 were never fast anyway as every hook instance had to copy the cache
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:
createRevalidatorcreateMutatoruseSwr<- 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
v4.1.0
v4.0.9
What's Changed
- [55] bound mutate unwrap + clone by @tronikelis in #56
- [57] bound mutate now is actually just a wrapper for matchMutate by @tronikelis in #58
Full Changelog: v4.0.8...v4.0.9
v4.0.8
v4.0.7
What's Changed
- [52] each store is a seperate obj by @tronikelis in #53
Full Changelog: v4.0.6...v4.0.7
v4.0.6
What's Changed
- remove awful things from useOptions by @tronikelis in #51
Full Changelog: v4.0.5...v4.0.6
v4.0.5
What's Changed
- call reconcile in different way by @tronikelis in #50
Full Changelog: v4.0.4...v4.0.5
v4.0.4
What's Changed
- better cleanup + some extra race condition things by @tronikelis in #49
Full Changelog: v4.0.3...v4.0.4

