Creating An API Dependency
The recommended approach to injecting dependencies into your apertures and handlers has been explored elsewhere - in the usage section and in a dependency injection recipe - but an important question has not been covered: what does a dependency look like?
While each app likely has obvious dependencies which would be useful inside Refract - such as your router or your Redux store - there are other dependencies which would benefit from the same approach.
This recipe explores one of the typical dependencies you might find yourself building: an API dependency.
Life Without an API Dependency
If we build an app without a centralised API dependency, we will eventually encounter a number of problems.
Repetition
Take a typical API request using fetch as an example. The request itself might look like this:
1
fetch(`https://api.github.com/users/${username}`)
2
.then(response => response.json())
3
.catch(error => console.error(error))
Copied!
When using fetch inside an aperture, there's actually a little extra boilerplate needed, and even worse it makes our aperture impure:
1
const aperture = component =>
2
component.observe('username').pipe(
3
mergeMap(username =>
4
fromPromise(
5
fetch(`https://api.github.com/users/${username}`)
6
.then(response => response.json())
7
.catch(error => ({ type: RECEIVE_ERROR, error }))
8
)
9
)
10
)
Copied!
The error catching logic is also problematic. If we take the approach shown above, we need to handle the different types of data being emitted inside one stream.
Alternatively, we could introduce even more boilerplate and handle errors directly in the stream:
1
const aperture = component =>
2
component
3
.observe('username')
4
.pipe(
5
mergeMap(username =>
6
fromPromise(
7
fetch(`https://api.github.com/users/${username}`).then(
8
response => response.json()
9
)
10
)
11
),
12
catchError(error => of({ type: RECEIVE_ERROR, error }))
13
)
Copied!
Neither feels like a clean solution - it's still a lot of overhead for a simple API request.
Flexibility
This approach makes the code harder to change. What if we want to migrate to a new version of the API, add an extra header to all requests, or add some common data transformation to a specific endpoint?
To make those changes, we would have to trawl through our app, find every API request, and consider the context of each request to make sure we're refactoring correctly.
Testability
Calling fetch inside our aperture makes our aperture impure, and we would have to use something like Jest's module mocking system to test it.
Request Cancellation
Depending on how we use the imperative fetch requests, we might not be able to cancel any in-flight requests.
The Solution
So what's the alternative?
The end goal is a dependency which can be added to our app much like a Redux store: a JavaScript object containing methods which we can call, isolating the impure code and wrapping it into a format which we can easily mock in tests.
1
const apiDependency = {
2
getUser: username =>
3
fromPromise(
4
fetch(`https://api.github.com/users/${username}`)
5
.then(response => response.json())
6
.catch(error => ({ error }))
7
)
8
}
9
​
10
ReactDOM.render(<App api={apiDependency} />)
Copied!
This dependency could then be exposed to Refract, allowing it to be called inside the apertures like so:
1
const aperture = (component, { api }) =>
2
component
3
.observe('username')
4
.pipe(mergeMap(username => api.getUser(username)))
Copied!
This is a much cleaner separation of concerns, allowing us to declaratively call our API endpoints - without caring about the implementation details, and without unnecessary repetition.
When refactoring the API, all the related code is in one place, and we no longer have to consider the context in which it is called. When testing, we can easily create a mock dependency, and our apertures remain pure.
Considerations
Using Your API Dependency Outside Refract
If you handle all of your app's side-effects via Refract, you have the opportunity to build your API dependency with this in mind.
By using primitives from your streaming library as building blocks, you can simplify features such as request cancellation, retry on error, or complex data transformations. Encapsulating your API into a single dependency lets you consider it in isolation, and makes your code clearer and more consistent.
However, using Refract that extensively might not be your goal - or you might need to migrate an existing app over time. In those cases, a centralised dependency would still provide some of those benefits, and could be a natural first step towards migrating.
The main difference in approach is that you would likely return raw promises instead of streams, so that they can be easily used outside Refract. You would still gain from the testability and consistency, and make it easier to refactor in future.
Runtime Configuration
Another significant advantage to this approach is that it can simplify runtime API configuration. For example, if you need to pass some data along with every request, you can achieve this by instantiating your api dependency inside a callback function:
1
const createApiDependency = ({ apiUrl, client }) => {
2
const apiHeaders = {
3
Authorization: client.authorization
4
}
5
​
6
const request = axios.create({
7
baseUrl: apiUrl,
8
headers: apiHeaders
9
})
10
​
11
return {
12
getUser: username =>
13
fromPromise(
14
request(`https://api.github.com/users/${username}`)
15
.then(response => response.json())
16
.catch(error => ({ error }))
17
)
18
}
19
}
Copied!
More complex configuration is also made possible via this separation of the API into its own isolated module.
Last modified 3yr ago