Slippers is not a networking library. It won’t make server calls for you (I have other libraries for networking).
What it will do, however, is make it easy for you to trigger network calls when you need to. It does this by providing some protocols and simple implementations thereof to control common network tasks like refreshing, paging, parsing, and type enforcement. Specifically, it provides:
- A protocol called
Refreshablewhich requires arefreshfunction - A functional implementation of
Refreshable - A ‘meta’ refresher class which will accept a bunch of
Refreshables and refresh all of them on command - A protocol called
Pageablewhich requiresnextPageandfetchPagefunctions - A functional implementation of
Pageable+Refreshablethat manages the page number for you - An extension to
Pageablethat can be used withUITableViewDelegates to simplify infinite lists - An array extension that allows you to use a simple array to simulate paginated batches of elements
- A class that makes a single
JSONEncoderandJSONDecoderavailable throughout your project with smart defaults set on them - An
IDclass that you can use transparently for integer server ids which helps enforce type consistency when passed around
Let’s talk about a couple of these in particular.
Refresher
Refresher implements Refreshable and accepts one argument in its init: a function of type () -> Void. This function gets called whenever the refresh method is called on this object.
Pager
Pager is a class that implements Pageable and Refreshable. It has an Int property that, when changed, will call the onPageUpdate function variable (which is passed in during init). So, when nextPage is called, the page property is incremented, which calls onPageUpdate, allowing you to do whatever you need in order to fetch or display the next page of data.
It also allows you to determine what Int counts as the ‘first’ page – that is, are your pages 0 indexed or do they start with page 1?
Finally, there’s an extension function on Pageable that helps with UITableView logic. Usually, when you’re building an infinite list, you want to know when the user is approaching the end of the data you’ve loaded; when they do, you want to fetch the next page’s worth. For table views, a common approach is to implement UITableViewDelegate and listen to the willDisplayCellForRowAtIndexPath function, waiting for the indexPath.row to get near the end of the list. This extension implements a function that allows you to configure:
- How large your page size is, and
- How far from the end of the list you should trigger fetching the next page
and then returns you a function that you can call from within willDisplayCellForRowAtIndexPath.
ID
If you’re familiar with the excellent PointFree series, then ID should be familiar; it’s just a simpler version of Tagged.
ID is a simple type designed to help the compiler keep you from making mistakes. Basically, you can use it in place of Int type ids on your server objects and fill in its generic requirement with the type you’re id-ing, and it will keep you from passing an ID for the wrong type to the wrong place. That’s a confusing sentence, so let’s look at an example:
struct Author {
var id: ID<Author>
...
}
struct BlogPost {
var id: ID<BlogPost>
var authorId: ID<Author>
...
}
By using ID instead of Int, you prevent yourself from accidentally trying to use a blog post id instead of an author id, or vice versa.
JsonProvider
This class provides static methods and static properties that allow you to do consistent encoding and decoding of JSON throughout your app. It sets as default ISO8601 date formatting and converting to/from snake case for property names. Both of these are the most common settings I see when dealing with JSON.
Additionally, it provides some static methods that use try! when encoding/decoding. These functions are great to use while testing your app, so you can fail fast and obviously when your objects are coded wrong.