Consider using functions instead of getter properties

This is most definitely a style preference, but I think many newcomers will be confused by the use of dynamically defined properties that return promises here, and I think they could lead to bugs due to their magicness.

Is there a rationale for preferring:

let html = await r2('https://www.google.com').text

over

let html = await r2('https://www.google.com').text()

Especially considering that the latter aligns with the Fetch API that users might be familiar with?

Since the promises returned here perform I/O, I think it’s a stronger signal to the reader to use functions instead of properties.

It’s a relatively well accepted maxim in languages that have had property methods for a while (eg, C#) that they should still be inexpensive wrappers to internal state instead of performing any real work – as this goes against users’ expectations of what a property is.

Again, totally just a personal preference – but I think it falls well within the principle of least astonishment.

[gr2m]

we will change the API to functions, just doing some spring cleaning first 🛁✨

[mhart]

@MaikuMori yeah, that’s wrong – fetch doesn’t retrieve the body of the response, only the status code and headers. Methods such as text(), json(), etc are the ones responsible for actually streaming the response body, as described here: https://fetch.spec.whatwg.org/#concept-body-consume-body

You can test this by fetching a very large file – the initial fetch promise will return quickly (with whatever latency the initial connection requires), and you’ll have your response object that you can get the status or headers from – but if you want the large body, you’ll need to resolve one of the body methods, and that will stream the rest of the response over the network.