4.1 comes with a more granular data definition hierarchy that will make it easier to
write more API definitions. This marked by the introduction of a new member known
as Entity. Entity only needs a pk() and get key(), as well
as member declarations to integrate fully.
4.0 marks the end of the migration to the new useCache() and useResource() implementations first introduced in 2.2. It also comes with a few other exciting features like a rewritten fetch based on the actual browser fetch API. Read below for more details and a migration guide.
2.2 comes with the eagerly awaited programmable optimistic updates. This enables two very important use cases: optimistic update on create and infinite pagination.
The bigger part of this release is introducing two new hooks that enable an incremental migration path to 3.0 planned changes. useCacheNew() and useResourceNew() are added in this release, allowing incremental adoption of the new selection logic that will become the default in 3.0. More details below.
Resource comes with a default fetch() implementation to make getting started easy.
It uses superagent as the networking library
due to its server-side support as well as nice interface via the builder pattern.
However, this comes at the cost of 6kb gziped added to the bundle. For those who want
to use another networking library this is quite a cost to pay for a library that itself
is well under 10kb gzip.
To solve this problem there is a new exported called SimpleResource. This provides
all the Resource behavior without the fetch() implementation. If you're customizing
fetch() or want to customize fetch(), simply follow the instructions to use
SimpleResource as your base class now. With tree-shaking this will leave superagent
out of your bundle and save a cool 6kb gzip.
Enable customizing networking library reducing bundle size #113
We use SemVer for Rest Hooks - so 2.0 represents some breaking changes. To minimize disruption we have been carefully considering these changes and awaiting community feedback to be confident these are the right changes to make.
While some of these changes are simple renames to make the library more intuitive - some represent important progress to empowering the next chapter of Rest Hooks.
See https://github.com/data-client/rest-hooks/releases/tag/2.0.0 for a complete list of changes