Fix: Don't add null values to query string.

[ChronosMasterOfAllTime]

This aims to resolve Feature Request #5107 and #5094

We added a "backwards compatibility" to allow serializing params with our own custom function instead of the current iterative toString approach.

[ghost]

Yes please!

[ChronosMasterOfAllTime]

@jasonsaayman were there merge conflicts? Seems like some odd things from the merge. (Like the readme for example)

[jasonsaayman]

Looks good 🚀

[ChronosMasterOfAllTime]

Thank you!

[havardthom]

This PR contradicts the discusssion here #1139 and solution here #1987

I have a use case for null query param, as many people in #1139 . Will this be added to Axios in the future?

[ChronosMasterOfAllTime]

This PR contradicts the discusssion here #1139 and solution here #1987

I have a use case for null query param, as many people in #1139 . Will this be added to Axios in the future?

Nulls were being included as empty string some_param=, not some_param=null. I would think you would want the latter. Also if your API is set to deserialze the QS it should automatically handle missing fields as null/nil/None/undefined.

[OzQu]

As far as I understood, there is multiple use cases to have query string with keys without values

  it('should support params', function () {
    expect(buildURL('/foo', {
      foo: 'bar',
      isUndefined: undefined,
      isNull: null
    })).toEqual('/foo?foo=bar&isNull');
  });

Could that be considered?

[ghost]

@OzQu I get the ask, however if you look at the behavior, an unset query Param returns an empty string when parsed via URLSearchParams

If you want null as a value for test, it would have to be handled by your API. I would think omitting the value is the equivalent of ?someVal when deserializing the request.

We can add it back in, but know it's up to the API to correctly handle this behavior when deserializing into your request object.