feat(url-prop-type): add URL prop type

[jaebradley]

Description

Adding validation for props that represent URL values might be more useful than using PropTypes.string.

Depends on the is-url package.

[jaebradley]

@ljharb thanks for the feedback! What commit syntax do you folks use? I can adjust my commit message accordingly.

[ljharb]

It's not super important, but I'd personally probably choose [New] AddurlpropType

[jaebradley]

@ljharb any additional comments? Thanks for all the feedback!

[AndyOGo]

whats going on with this pr?

[ljharb]

I'm not convinced it's valuable - literally any string could be a URL.

[AndyOGo]

Thanks for your viewpoint. I'm totally astonished, to me it seems that is one of the most ignorant statements I have encountered in the field of computing. RFC 3986 clearly defines that not any string could be an URL 😕

[ljharb]

@AndyOGo that kind of response is needlessly hostile and won't be tolerated on any of our repos.

The RFC isn't the relevant standard - it's "what could go in a link's href attribute". That, indeed, can be any string.

[AndyOGo]

@ljharb Thanks for your quick response.

I'm sorry if I'm too direct, though I assume that a decision is made here based on subjective feeling. Though the HTML 5 living standard clearly defines what an href is expected to be:

The href attribute on a and area elements must have a value that is a valid URL potentially surrounded by spaces.

May I ask for objective resources, that proof your statements?

[ljharb]

Alright, then what is an example of something that you could put in an href, and it would result in an unclickable URL?

[AndyOGo]

Thanks for your quick reply.

You are right if you mean, that a relative URL would not need any slashes like foo. But it would be nice to be able to test URLs either absolute URIs including various protocols like http, file, javascript or relative ones with just a /path or even #fragment-identifiers or escaping of special chars - that's not any string to me.

PS: browser's quirks-mode does not count

[ljharb]

Validating that something is a fully proper URL is already achievable with a function (or the is-url module, for example); propTypes are most useful for React components, which tend to be focused on producing HTML, so I'm not convinced there's sufficient value in having that propType here.

[AndyOGo]

Alright. I got your point. I fully agree that JSX produces HTML and since URLs, links, hrefs, src etc, are an inherently intrinsic part of it I would favor proper prop type checking for URLs. Since links or hyperlinks are one of the visionary innovations of hypertext in contrast to text I consider them essential.

Just for your interest I took the time to dig again through all those specs to provide you with objective resources - may I ask you to examine all of it?: https://www.w3.org/TR/html5/single-page.html#valid-url-potentially-surrounded-by-spaces

A string is a valid URL potentially surrounded by spaces if, after stripping leading and trailing white space from it, it is a valid URL.

https://www.w3.org/TR/html5/single-page.html#valid-url

A URL is a valid URL if it conforms to the authoring conformance requirements in the WHATWG URL specification. [URL]

https://www.w3.org/TR/html5/single-page.html#biblio-url

Note: URLs can be used in numerous different manners, in many differing contexts. For the purpose of producing strict URLs one may wish to consider [RFC3986] [RFC3987]. The W3C URL specification defines the term URL, various algorithms for dealing with URLs, and an API for constructing, parsing, and resolving URLs. Developers of Web browsers are advised to keep abreast of the latest URL developments by tracking the progress of https://url.spec.whatwg.org/. We expect that the W3C URL draft will evolve along the Recommendation track as the community converges on a definition of URL processing.

Most of the URL-related terms used in the HTML specification (URL, absolute URL, relative URL, relative schemes, scheme component, scheme data, username, password, host, port, path, query, fragment, percent encode, get the base, and UTF-8 percent encode) can be straightforwardly mapped to the terminology of [RFC3986] [RFC3987].

[jaebradley]

As the author of this PR, I agree that there is probably insufficient value here and will be closing this PR.

[ljharb]

@jaebradley thanks for the contribution and sorry this took so long