For me, I tend to put `node-fetch` onto `global.fetch` so that it's generally available like in modern browsers. If you have to support older browsers, could always use `isomorphic-fetch` for shared modules. I prefer to assume it's globally available and write to that.
It's not exactly the same, but close enough that I rarely have issue with client-server modules.
👍
I have been using Axios for my last few projects, and been pretty happy with it, but less dependencies is always better!
I wish fetch's api required less boilerplate, I would only use fetch too.
Yeah, it's a mixed bag, I usually wrap it up in something that works with my API structure better... (posting a gist to link now). The normalizeRequest[1] default export handles a lot of the issues for me. (note using elvis operator[2] via babel).
With that in place, a lot of my api-client comes down to things like:
import callAPI, { headRequest } from './request';
export const check = id =>
headRequest(`/petition/${encodeURIComponent(id.toUpperCase())}`).then(
r => r && r.statusCode === 200
);
export const dashboard = id =>
callAPI('GET', `/petition/${encodeURIComponent(id.toUpperCase())}/dashboard`);
export const create = petition => callAPI('POST', '/petition', petition);
[1] https://gist.github.com/tracker1/0b0522b840573171edffd31df50b381a
[2] https://babeljs.io/docs/en/babel-plugin-proposal-optional-chaining