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

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

From: Anne van Kesteren <annevk@annevk.nl>
Date: Fri, 22 Aug 2014 11:26:52 +0200
Message-ID: <CADnb78hhe5Y4GrKthq3srYs=s6-EDaSb+roktUUTksSErHEVvQ@mail.gmail.com>
To: Jake Archibald <jaffathecake@gmail.com>
Cc: James Graham <james@hoppipolla.co.uk>, WHATWG <whatwg@lists.whatwg.org>, Alex Russell <slightlyoff@google.com>
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/
Received on Friday, 22 August 2014 09:27:16 UTC

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