Move axios request config option into main uploadTable options argument

[waxlamp]

This cleans up the calling sequence for uploadTable, enabling the caller to place any axios config values into a special entry in the options argument, rather than having to supply it as a separate argument. This makes the calling sequence easier to parse in the code, and makes it explicit what the formerly separate argument is for.

The two calls to uploadTable in the multinet-client codebase will benefit from this change.

[jjnesbitt]

I'm actually opposed to this change, mainly because I think all (or at least most) of the methods in the API should have this option associated with it, and since they don't all contain an options parameter, I think having a final optional config parameter is the most consistent way to provide this option to all of the methods. It may lead to a few messier function calls, but those calls aren't exactly pretty to begin with anyway.

[waxlamp]

I'm actually opposed to this change, mainly because I think all (or at least most) of the methods in the API should have this option associated with it, and since they don't all contain an options parameter, I think having a final optional config parameter is the most consistent way to provide this option to all of the methods. It may lead to a few messier function calls, but those calls aren't exactly pretty to begin with anyway.

The thing is, these are in fact options for the function call. If we have to add an axios request config to each function's specialized options, that's not really an issue for me. And the fact that the function calls are not pretty to begin with is not a good argument for making them even uglier 🐱

We can also leverage typescript for this if needed: there can be a general Options type that contains the axios request config, and the individual option types for each function can simply extend it.

I remain strongly in favor of this, because eventually people besides us will be using this library, and having two separate option arguments for each function, the latter of which is optional, will be very confusing. Both pain points are solved simply by allowing people to specify their axios options in the same place as all other options.

[jjnesbitt]

@waxlamp and I discussed more offline, and decided that including the axiosRequestConfig parameter in a more generally purposed Options type would be the way to go. For exposing this config to other functions, it's a matter of either adding an options: Options parameter, or changing the type of the existing options parameter to extend the new Options type.

[jjnesbitt]

Regarding my previous comment, my ask would be to factor out the axiosRequestConfig field into the general Options interface, and changing FileUploadOptionsSpec to extend that.

[waxlamp]

Regarding my previous comment, my ask would be to factor out the axiosRequestConfig field into the general Options interface, and changing FileUploadOptionsSpec to extend that.

Done in d27d043.

We're set up to add axiosRequestConfig to the other functions, though I don't think we should do it until it's needed (or at least, if we do it without a specific need, let's do it on a different PR).

[jjnesbitt]

Done in d27d043.

We're set up to add axiosRequestConfig to the other functions, though I don't think we should do it until it's needed (or at least, if we do it without a specific need, let's do it on a different PR).

Agreed