Should I setHeaders each time I'm creating an API? about apisauce

[skellock]

Where do the headers come from? Are they known at api creation time? It sounds like you're saying they may not be.

Each api will need to be told it's headers. You can do this at creation time api.create({ headers: {} }). Or you can do it later via api.setHeader('X-SOMETHING', 'ABCDEF').

[Blackening999]

Some of them know at api creation time, some of them not.
I'm receiving headers from saga loginFlow. Other places I'm using API.create (which return api in turn) do not know about that update. So no, I cannot do api.setHeader :\
The only possible solution is to use a global namespace for api and use api.setHeader('X-SOMETHING', 'ABCDEF'), for create I have to bake api.create each time with headers which is even worse

[skellock]

I don't think recreating your api every request is a bad thing. That'll only add like 1 or 2ms onto a network request that takes .. what... 50ms? maybe?

Another option to look at is installing a response transform to all APIs which will sniff out your api responses for tokens & add them there.

[Blackening999]

@skellock this might be interesting about request transforms. how should I declare it?
I have an api in the form of

// a library to wrap and simplify api calls
import apisauce from 'apisauce'

// our "constructor"
const create = (baseURL = 'http://localhost:3000') => {
  // ------
  // STEP 1
  // ------
  //
  // Create and configure an apisauce-based api object.
  //
  const api = apisauce.create({
    // base URL is read from the "constructor"
    baseURL,
    // here are some default headers
    headers: {
      Accept: 'application/json'
    },
    // 10 second timeout...
    timeout: 10000
  })

  // Force OpenWeather API Key on all requests
  // api.addRequestTransform((request) => {
  //   request.params['APPID'] = '0e44183e8d1018fc92eb3307d885379c'
  // })

  // Wrap api's addMonitor to allow the calling code to attach
  // additional monitors in the future.  But only in __DEV__ and only
  // if we've attached Reactotron to console (it isn't during unit tests).
  if (__DEV__ && console.tron) {
    api.addMonitor(console.tron.apisauce)
  }

  // ------
  // STEP 2
  // ------
  //
  // Define some functions that call the api.  The goal is to provide
  // a thin wrapper of the api layer providing nicer feeling functions
  // rather than "get", "post" and friends.
  //
  // I generally don't like wrapping the output at this level because
  // sometimes specific actions need to be take on `403` or `401`, etc.
  //
  // Since we can't hide from that, we embrace it by getting out of the
  // way at this level.
  //
  const getCity = (city) => api.get('weather', {q: city})

  const login = (email, password) => api.post('/oauth/token', { email, password, grant_type: 'password' })

  // ------
  // STEP 3
  // ------
  //
  // Return back a collection of functions that we would consider our
  // interface.  Most of the time it'll be just the list of all the
  // methods in step 2.
  //
  // Notice we're not returning back the `api` created in step 1?  That's
  // because it is scoped privately.  This is one way to create truly
  // private scoped goodies in JavaScript.
  //
  return {
    // a list of the API functions from step 2
    getCity,
    login
  }
}

// let's return back our create method as the default.
export default {
  create
}

I'm interesting how can apply transform considering the fact I'm originally using API as a function which returns the result of creating a new api )

[skellock]

You'd have to pass it in, define it inside, or expose it as a key in the return of that function. A few options, but really, it's up to you.

[Blackening999]

Wait, you mean if I'll pass transform into a function once it'll be pulled up globally on any consecutive call? If you can provide a short example I'll be much appreciated ;)

[skellock]

Not globally, but for the lifespan of that instance yep. There's some examples of these transforms on the readme. Hope that works for ya.