fix(common): add HttpParamsOptions to the public api

[rwlogel]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Documentation content changes
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• angular.io application / infrastructure changes
• Other... Please describe:

What is the current behavior?

The HttpParamsOptions is not documented or included in the public API even though it is a constructor argument of HttpParams which is in the public API.

Issue Number: #20276

What is the new behavior?

HttpParamsOptions will be included in the public API and documented.

Does this PR introduce a breaking change?

• Yes
• No

Other information

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[IgorMinar]

This is not a doc's change. Can you please change this comment to be a fix thank you

[gkalpak]

For context: #20332 and #23015

[rwlogel]

The reason I think we should expose the interface instead of making it inline as part of the HttpParams structure is because it makes extending HttpParams less complicated. This is the situation where I wanted to use it to work around #11058:

export class PlusSafeQueryEncoder implements HttpParameterCodec {
  encodeKey(key: string): string {
    return encodeURIComponent(key);
  }

  encodeValue(value: string): string {
    return encodeURIComponent(value);
  }

  decodeKey(key: string): string {
    return decodeURIComponent(key);
  }

  decodeValue(value: string): string {
    return decodeURIComponent(value);
  }
}

export class PlusSafeHttpParams extends HttpParams {
  constructor(options?: HttpParamsOptions = {} as HttpParamsOptions) {
    super({ ...options, encoder: new PlusSafeQueryEncoder() })
  }
}

[gkalpak]

Sounds reasonable to me.

You can always grab the type from the HttpParams constructor, but it still sounds reasonable to use an interface:

type MyHttpParamsOptions = ConstructorParameters<typeof HttpParams>[0];

[jelbourn]

LGTM

Reviewed-for: public-api

[AndrewKushnir]

Thanks for updating this PR!

I've also checked that the HttpParamsOptions is displayed correctly (see here) and also started tests in Google's codebase (internal-only link).

Note: this PR should be ready for merge once all tests are completed and there is a final approval from the fw-http group (cc @alxhub).

Thank you.

[alxhub]

Reviewed-For: public-api

[AndrewKushnir]

Started a new presubmit, will keep this thread updated.

[AndrewKushnir]

FYI, presubmit is successful for the changes in this PR. Thank you.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}