Skip to main content

Rest Hooks 2.1 Released

· 3 min read
Nathaniel Tucker

New Features

Reduced bundle size with custom networking library

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

RPCAction, PurgeAction

RPCAction, PurgeAction types join ReceiveAction and FetchAction as exportes from Rest Hooks. Internally Rest Hooks dispatches actions (plain objects) that describe what Rest Hooks should do. The structure of these actions is typed and previously only some of those types were actually exported. Now you can get access to all of them. This is most useful for building your own custom managers.

Export new types RPCAction, PurgeAction #119

Improved Debugging

Sometimes the backend can fail and return bad responses - even without an HTTP error code. It would behoove any fetching library to gracefully handle those cases and inform the user what happened.

Previously there was a check for this very case - but it was only included in development mode. Having certain bug checking code only exist in development mode makes sense for errors that would exist and be caught in the client code. However, for issues independant of client (like servers) this is an unreasonable restriction.

To solve this, the default fetch() implementation in Resource has been updated to check for valid responses even in production. Its checking logic has also been improved. Additionally the internal action dispatching types have been updated to not allow void responses for anything besides a PurgeAction. This is important to enforce voids are not passed around as they have no meaning as the result of a fetch. This leads the way to further type refinements that enforce this as the FetchShape.fetch() level as to ensure user implementations provide those same guarantees.

Now even in production - if the API soft errors by returning an invalid response without an error status code you will get a "JSON expected but not returned from API" error response.

Handle null fetch response even in production #119

Type refinements

String is considered a valid payload to be sent in requests, so it has been added to the union along with object. This makes API really as flexible as it should be.

Allow string type for body (payload) parameters

Final notes

Please try out the new release and give feedback if there are any issues or if things are working great! We've got a lot of great new features coming down the pipeline and we hope to see your contributions as well. 😊

Full set of 2.1 release commits