@mhevery I think that we need to enforce both - compile-time type checking but also run-time type checking for ES5 DSL users.

However, there’s small problem for enforcing compile-time type checking by using mandatory url field in RequestOptionsArgs because it is used in both:

Request and…
Http method aliases like get, post, etc. where we pass the url as first argument and we don’t need it in the second parameter which is of type RequestOptionsArgs

As a solution we can refactor RequestOptionsArgs to be an interface and make the url mandatory. After that we can extend it like this:

export interface RequestOptionsAliasArgs extends RequestOptionsArgs {
  url?: string;
}

This way we can request second parameter of type RequestOptionsAliasArgs to get, post, etc. and use RequestOptionsArgs for Request. And from semantical point of view I think makes sense since RequestOptionsArgs is more generic compared to RequestOptionsAliasArgs.

The run-time type checking we can enforce with:

if (!options.url) {
  makeTypeError(‘…’);
}

As drawback I see one more interface to be documented but I don’t see any other clean way for doing this.

@jeffbcross @mhevery what are your thoughts on this? I can open a pull request if you think it sounds fine.

chore(http): assert that url is present in RequestOptions when creating a Request #2806

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions