W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2014

Re: [whatwg] [Fetch] API changes to make stream depletion clearer/easier

From: Brian Kardell <bkardell@gmail.com>
Date: Fri, 22 Aug 2014 13:15:05 -0400
Message-ID: <CADC=+jcwDiyYtoBjfDt=wbWjZMVQZSExb3yp52mFsNEUPM6oFQ@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: James Graham <james@hoppipolla.co.uk>, WHATWG <whatwg@lists.whatwg.org>, Alex Russell <slightlyoff@google.com>, Jake Archibald <jaffathecake@gmail.com>
On Fri, Aug 22, 2014 at 5:26 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Fri, Aug 22, 2014 at 10:32 AM, Jake Archibald <jaffathecake@gmail.com> wrote:
>> On 22 August 2014 07:20, Anne van Kesteren <annevk@annevk.nl> wrote:
>>> That works for me too. I agree that developers will likely learn what
>>> is going on here quickly enough. And that if anything should have long
>>> names, it would be some new API that would use more memory. Jake?
>> Reading a url as some format is really common, so I'm in favour of shorter
>> method names.
>> var data = await (await fetch('/whatever')).asJSON();
>> The consuming behaviour may catch some developers out, once, in their
>> development environment.
>> I don't think Alex & Domenic were as keen & wanted something in the name to
>> represent consuming/taking.
> James pointed out on IRC we could simply have this:
>   response.json()
>   response.text()
>   request.formData()
> I did not like this at first. However, if we care about brevity, and
> we often said we do and act in that manner (see e.g. querySelector ->
> query), he is right. "as" does not really add anything. "bodyAsJSON"
> is a bit more descriptive and "takeBodyAsJSON" is even more, but in
> the end everyone will know very quickly that response/request can only
> have their body read once and will dislike us for having to type those
> extra characters (and will then type another couple to complain about
> it on Twitter).
> I checked and none of the existing properties clash with data types we
> might want to add in the future. I think those, combined with exposing
> state through hasBody should be the way forward.
> --
> http://annevankesteren.nl/

I still think that calling it bodyStream actually helps understanding
all you need and it's short/portable...


seems to at least give the hint that it is a stream that is consumed
without getting too crazy.

Brian Kardell :: @briankardell :: hitchjs.com
Received on Friday, 22 August 2014 17:15:31 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:22 UTC