Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more cross-links #872

Merged
merged 4 commits into from
Jan 31, 2018
Merged

Add more cross-links #872

merged 4 commits into from
Jan 31, 2018

Conversation

surma
Copy link
Contributor

@surma surma commented Jan 26, 2018

This PR does not contain functional changes.

I found the spec to be a bit frustrating to browse when I was trying to figure out which methods are on a stream, a stream controller or the underlying sink/source. I am linkifying a couple of things to make the spec more navigational.

Please mind that this is my first work with bikeshed so I might not be doing it right, don’t hesitate to make me correct things.

PTAL :)


Preview | Diff

index.bs Outdated
@@ -444,11 +444,11 @@ ReadableStream(<var>underlyingSource</var> = {}, { <var>size</var>, <var>highWat
govern how the constructed stream instance behaves:

<ul>
<li><p><code>start(controller)</code> is called immediately, and is typically used to adapt a <a>push
<li><p><code>start({{ReadableStreamDefaultController|controller}})</code> is called immediately, and is typically used to adapt a <a>push
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one is a bit questionable because it could also be a BYOB, but I think having it clickable is worth the simplification.

Copy link
Member

@domenic domenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some good stuff here, thanks!

In addition to specific issues noted, let's be sure the final patch rewraps to the 120-character column limit.

index.bs Outdated
@@ -95,7 +95,7 @@ A <dfn export>readable stream</dfn> represents a source of data, from which you
<em>out</em> of a readable stream. Concretely, a readable stream is an instance of the {{ReadableStream}} class.

Although a readable stream can be created with arbitrary behavior, most readable streams wrap a lower-level I/O source,
called the <dfn>underlying source</dfn>. There are two types of underlying source: push sources and pull sources.
called the <dfn>underlying source</dfn> ([[#rs-constructor|interface description]]). There are two types of underlying source: push sources and pull sources.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't good, because we're currently talking about the general concept of underlying sources, not the JS objects that sometimes (for web-developer-created streams) embody them. Such a link belongs later, where we say "For web developer–created streams, the implementation details of a source are provided by an object with certain methods and properties that is passed to the ReadableStream() constructor." But, that already links to the constructor, so I'm not sure if there's anything to do here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your point. The problem that I’m trying to solve here is the following flow:

  1. Go to stream spec
  2. Click “ReadableStream” in ToC
  3. Get confused, maybe click ReadableStream again?
  4. Okay, I’m at the class, I see underlyingSource, but I can’t click it. The paragraph has a clickable “underlying Source”, tho. So let’s click that.
  5. I was already here...

Maybe we can turn underlyingSource in the class definition into a link to the note? Would that be acceptable?

index.bs Outdated
@@ -137,7 +137,7 @@ A <dfn export>writable stream</dfn> represents a destination for data, into whic
goes <em>in</em> to a writable stream. Concretely, a writable stream is an instance of the {{WritableStream}} class.

Analogously to readable streams, most writable streams wrap a lower-level I/O sink, called the
<dfn>underlying sink</dfn>. Writable streams work to abstract away some of the complexity of the underlying sink, by
<dfn>underlying sink</dfn> ([[#ws-constructor|interface description]]). Writable streams work to abstract away some of the complexity of the underlying sink, by
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same problem as above.

index.bs Outdated
@@ -385,15 +385,15 @@ like

<pre><code class="lang-javascript">
class ReadableStream {
constructor(underlyingSource = {}, { size, highWaterMark } = {})
<l>[[#rs-constructor|constructor]]</l>(underlyingSource = {}, { size, highWaterMark } = {})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I find this more confusing than just doing <a href="#rs-constructor">constructor</a>. Does that work, or is only <l> allowed inside <pre> blocks?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just tested it. Works as well.

index.bs Outdated
@@ -444,11 +444,11 @@ ReadableStream(<var>underlyingSource</var> = {}, { <var>size</var>, <var>highWat
govern how the constructed stream instance behaves:

<ul>
<li><p><code>start(controller)</code> is called immediately, and is typically used to adapt a <a>push
<li><p><code>start({{ReadableStreamDefaultController|controller}})</code> is called immediately, and is typically used to adapt a <a>push
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not really OK with linking variable names to their types in general, here or elsewhere. (Especially, as you say, when their types are not accurate.) If you think it's unclear what the type of the controller is, we should add a more explicit sentence explaining.

This occurs several times below; I'll avoid noting it each time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That’s fair. I’ll take a stab at rephrasing the text so I can add some links to that instead.

@@ -385,15 +385,15 @@ like

<pre><code class="lang-javascript">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The introduction of links into these blocks is a great improvement; thank you!

@surma
Copy link
Contributor Author

surma commented Jan 27, 2018

Fixed line length and moved some of the links away from the code blocks into the descriptive text. PTAL :)

index.bs Outdated

<li>
<p><code>transform(chunk, controller)</code> is called when a new chunk originally written to the writable side is
ready to be transformed. It can return a promise to signal success or failure of the transformation. The results
of the transformation can be enqueued to the readable side using the
{{ReadableStreamDefaultController/enqueue(chunk)|controller.enqueue()}} method. This permits a single chunk
written to the writable side to result in zero or multiple chunks on the readable side.
{{TransformStreamDefaultController|controller}}.{{TransformStreamDefaultController/enqueue(chunk)|enqueue()}}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about splitting the links to contain both the class definition as well as the method definition?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additionally, was it intentional that this linked to ReadableStreamDefaultController.enqueue() instead of TransformStreamDefaultController.enqueue()

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm 99% sure that linking to ReadableStreamDefaultController.enqueue() was a mistake here. Thanks for catching it.

Splitting the links looks okay to me, but I will defer to @domenic who knows much more about correct markup fro WhatWG standards.

index.bs Outdated
@@ -385,15 +385,16 @@ like

<pre><code class="lang-javascript">
class ReadableStream {
constructor(underlyingSource = {}, { size, highWaterMark } = {})
<a href="#rs-constructor">constructor</a>(<a href="#rs-constructor">underlyingSource</a> = {}, { size, highWaterMark
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realize linking underlyingSource to ReadableStream() could be seen as questionable. This is just as suggestion. My thinking was that if someone’s looking at the class definition and the constructor, they are most likely a web developer and looking for an interface description. There’s multiple links to underlyingSource in the note, so there’s still a path to the definition.

Copy link
Member

@domenic domenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay. A few minor nits, and suggestion for a larger fix that I (or you) can work on as a follow-up.

web developer–created streams, the implementation details of a source are provided by an object with certain methods and
properties that is passed to the {{ReadableStream()}} constructor.
Readable streams are designed to wrap both types of sources behind a single, unified interface. For web
developer–created streams, the <a href="#rs-constructor">implementation details of a source</a> are provided by an
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still not sure this helps that much compared to just clicking on the already-existing "ReadableStream() constructor" link, but I'm OK keeping it if you think so.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It mostly because of the point below, that as a reader it’s not obvious that the underlying source is defined at the constructor. I’d prefer leaving this link for now until we give underlyingSource its own section.

index.bs Outdated
@@ -385,15 +385,15 @@ like

<pre><code class="lang-javascript">
class ReadableStream {
constructor(underlyingSource = {}, { size, highWaterMark } = {})
<a href="#rs-constructor">constructor</a>(<a href="#rs-constructor">underlyingSource</a> = {}, { size, highWaterMark } = {})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again the second link to the exact same place feels pretty redundant.

Maybe what this is pointing toward is the need for a dedicated section describing the underlying source objects, instead of putting it into the constructor's intro note? I guess same for the strategies too? I'd be happy to work on that as a follow-up. In the meantime I'm indifferent as to whether we include these redundant links or not.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The more I work on this, the more I think that’s the actual crux: Something as integral to developing streams shouldn’t just be defined in a note. So I’m up for formalizing underlyingSource and underlyingSink, but defo need some guidance what the right formalism is here.

I’ll remove the links.

index.bs Outdated
@@ -2778,12 +2778,13 @@ like

<pre><code class="lang-javascript">
class WritableStream {
constructor(underlyingSink = {}, { size, highWaterMark = 1 } = {})
<a href="#ws-constructor">constructor</a>(<a href="#ws-constructor">underlyingSink</a> = {}, { size, highWaterMark =
1 } = {})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot that line wrapping is not a good idea inside <pre> blocks; sorry, we should undo this.

index.bs Outdated
that will be read from the <a>readable side</a> but don't depend on any writes to the <a>writable side</a>. If
this process is asynchronous, it can return a promise to signal success or failure.
using
{{TransformStreamDefaultController|controller}}.{{TransformStreamDefaultController/enqueue(chunk)|enqueue()}}.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather not have separate links for the controller since that's just a variable name, and it is described below. So just changing the linking text from enqueue() to controller.enqueue() is probably best here.

index.bs Outdated

<li>
<p><code>transform(chunk, controller)</code> is called when a new chunk originally written to the writable side is
ready to be transformed. It can return a promise to signal success or failure of the transformation. The results
of the transformation can be enqueued to the readable side using the
{{ReadableStreamDefaultController/enqueue(chunk)|controller.enqueue()}} method. This permits a single chunk
written to the writable side to result in zero or multiple chunks on the readable side.
{{TransformStreamDefaultController|controller}}.{{TransformStreamDefaultController/enqueue(chunk)|enqueue()}}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also change this one?

Copy link
Member

@domenic domenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot to mention we should probably also cross-link the other class definitions in the same way you did for the big three. But, also fine as a follow-up :)

Thanks so much!

@domenic domenic merged commit d7a57bb into whatwg:master Jan 31, 2018
domenic added a commit that referenced this pull request Jan 31, 2018
In particular, the underlying source API, the underlying sink API, the transformer API, and queuing strategy objects.

This is inspired by some of the discussion in #872. The new locations for these definitions allow us to link to them, and the more spacious format allows us to flesh out more aspects of the behavior of each option. In particular, this tries to clarify how the return value of an underlying sink's write() method is used, per conversations with Lennart Grahl.
domenic added a commit that referenced this pull request Feb 7, 2018
In particular, the underlying source API, the underlying sink API, the transformer API, and queuing strategy objects.

This is inspired by some of the discussion in #872. The new locations for these definitions allow us to link to them, and the more spacious format allows us to flesh out more aspects of the behavior of each option. In particular, this tries to clarify how the return value of an underlying sink's write() method is used, per conversations with Lennart Grahl.
domenic added a commit that referenced this pull request Feb 22, 2018
In particular, the underlying source API, the underlying sink API, the transformer API, and queuing strategy objects.

This is inspired by some of the discussion in #872. The new locations for these definitions allow us to link to them, and the more spacious format allows us to flesh out more aspects of the behavior of each option. In particular, this tries to clarify how the return value of an underlying sink's write() method is used, per conversations with Lennart Grahl.
domenic added a commit that referenced this pull request Feb 22, 2018
In particular, the underlying source API, the underlying sink API, the transformer API, and queuing strategy objects.

This is inspired by some of the discussion in #872. The new locations for these definitions allow us to link to them, and the more spacious format allows us to flesh out more aspects of the behavior of each option. In particular, this tries to clarify how the return value of an underlying sink's write() method is used, per conversations with Lennart Grahl.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants