JavaScript Chat Summary: March 31, 2020

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript). Many thanks to @c4rl0sbr4v0 for compiling these notes!

TypeScript Types from Packages

(Slack conversation)

WordPress packages will now ship with their own first-party TypeScript types!

Pull request: https://github.com/WordPress/gutenberg/pull/18942

The types (declaration files) will be published with the packages, so folks using the packages via npm will have access without doing anything else.

The type generation is built into the existing package build/publish flow, so things should remain largely the same from the perspective of Gutenberg development (hopefully with better information in our IDEs!)

npm run build:package-types is the script that generates them.

Awesome job! Kudos!

Action:

JSX support for wordpress/scripts

(Slack conversation)

Link to the issue

PR proposing it for formatting command.

There is a small discussion about seeing if it is necessary to discourage or not jsx files. Noticing that changes to accept jsx are quite simple. And are even accepted in some code already. There are different opinions, so the team prefer to continue the discussion.

Action: 

Open Floor

Updating Jest Error

@gziolo had issues upgrading Jest with the last version. See pull request. Asks if is it a good reason to refactor them to use the React Testing Library?

@aduth comments that is Enzyme related issue. That expects a DOM to exist.

Airbnb transferred the project to the community. Seems that everyone is going to switch away from Enzyme.

Also they comment that Jest, Babel and Puppeteer should be upgraded, and would be nice to have some strategya arount all that. The project seems to have too many dependencies.

Action:

  • No action defined.

News Roundup

This roundup contains a few links for Gutenberg and JavaScript related news curated (and commented on) by @nerrad.

#core-js, #javascript

JavaScript Chat Summary: March 17, 2020

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack transcript).

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Agenda Items

JSDoc Documentation Standards

(Slack conversation)

Question: Does it make sense to document changes to a function over time, and if so, how?

Context: https://github.com/WordPress/gutenberg/pull/20427#discussion_r386396607

The current JavaScript documentation standards restrict the @since tag to include only the version number:

@since x.x.x: Should always be 3-digit (e.g. @since 3.6.0).

This is in contrast to the PHP documentation standards, which include guidelines around using @since as a changelog:

If significant changes have been made to a function, hook, class, or method, additional @since tags, versions, and descriptions should be added to provide a changelog for that function.

Proposal: Incorporate some adaptation of the PHP since changelog guidelines into the JavaScript inline documentation standards.

Discussion Points:

  • @nerrad asks if this could be used to pull documentation automatically from the source code. This is quite possible, and is likely exactly what is done with the PHP source code documentation (example documentation and source).

Action Items:

  • Update the JS documentation standards, assuming there is no opposition presented in the coming days.
  • Disable the JSDoc since format validation for Gutenberg in the related changelog (already done)

News Roundup

This roundup contains a few links for Gutenberg and JavaScript related news curated (and commented on) by @nerrad

Other Random Stuff:

#core-js, #javascript

JavaScript Chat Summary: March 10, 2020

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack transcript).

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

News roundup proposal

(Slack conversation)

@nerrad as been kind enough to offer to share an aggregate of news relevant in the Gutenberg and general JavaScript ecosystem, to include in the summary notes for each week’s meeting.

Discussion:

  • There was an agreement that it’s a great idea.
  • The plan is to add this as an extra section in our JavaScript chat summary starting from this week.

Action items:

  • New agendas should be structured to include separate sections “Agenda Topics” and “News Roundup”
  • Note-takers should aim to include these items in the published summary notes.
  • Update “Note Takers” document guidelines.

ESLint “prefer-const” relaxation proposal

(Slack conversation)

@aduth added a pull request about a potential revision to our default ESLint configurations (i.e. coding standards) at https://github.com/WordPress/gutenberg/pull/20737. He just wanted to bring it to attention, since any of these sorts of coding standards changes are good to highlight. There’s been some positive feedback already on the pull request that was echoed in the chat.

Visual regression testing tools

(Slack conversation)

@isabel_brison created a ticket https://core.trac.wordpress.org/ticket/49606 to introduce visual regression testing in the WordPress core, so we can clean up some of the old CSS with confidence. She was wondering if this type of testing has been discussed or explored at all for core or Gutenberg. Also, would there be value in adding it for Gutenberg, too?

Discussion:

There’s no visual regression testing in Gutenberg as of today, but there are parts of the tooling that could make it possible, like taking screenshots with the headless browser via Puppeteer. At least with the ticket as presented, it seems primarily focused on existing screens which may not be expected to change, and thus primarily with the aim of preventing regressions while doing CSS refactoring.

The tests themselves are minimal, but the reference images are not insignificant though and need to be updated periodically. The biggest concern is the size of the assets that would have to be maintained and how to ensure they don’t pollute repositories with source code.

There is an existing prototype in the Gutenberg repository (https://github.com/WordPress/gutenberg/pull/18797) that uses 3rd party service percy.io that can be used as a reference when exploring the final implementation.

Introduce a common API to style Button from both web and mobile

(Slack conversation)

There is a pull request that explores primitive UI components that can be used both in native mobile apps and in the browser: https://github.com/WordPress/gutenberg/pull/19104. There was no specific discussion item attached to this, but it was requested that anyone interested take a look and provide any feedback they have to drive further development.

News roundup

A few links to Gutenberg and JavaScript related news (curated by @nerrad).

WordPress 5.4 dev notes

Other random stuff

#core-js, #javascript

JavaScript Chat Summary: February 25, 2020

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack transcript).

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Unit testing revisited

(Slack conversation)

The current tooling used for component testing in Gutenberg was observed to not support support React portals. An implementation of a new testing utility module was originally proposed, then later resubmitted as an incremental approach to adopt React Testing Library.

Discussion:

  • Is this about limitations of the tooling for fundamental React features, or about our approach to testing? It appears to be a little of both.
  • The conversation evolved into a discussion of how we want to test components, essentially distilled to a distinction between white-box and black-box testing.
  • There was some unclarity around what impact React Testing Library would have on our existing tools. @hazdiego joined the conversation, pointed to an earlier GitHub comment contrasting the solutions, and clarified that while it has feature parity to support replacing existing tools, it also comes opinionated with integration-style testing.

Action items:

Open Floor

WordPress 5.4 Deadlines

(Slack conversation)

@adamsilverstein made note that the WordPress 5.4 release is quickly approaching and that any work not addressed soon would need to be punted to a future release.

@aduth mentioned that a polyfill fix for URL will be needed, and that he would appreciate attention on the corresponding patch at #49360.

Webpack Build

(Slack conversation)

@gziolo mentioned that changes to the Webpack build were introduced with #48154, where one asset file is created containing all JavaScript entry points. This generated file is used to iterate and register all core scripts output from the Webpack build.

@gziolo mentioned a desire to improve upon this with better handling between development and production environments. He gave an example of the wp-warning package, which should be considered unnecessary for production, since it is a noop in that environment. Due to time constraints, this is planned to be discussed further in next week’s meeting.

#core-js, #javascript

JavaScript Chat Summary: January 28, 2020

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack transcript).

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Create block package

(Slack conversation)

New @wordpress/create-block package was merged in the past week: https://github.com/WordPress/gutenberg/pull/19773. The package is meant to help plugin developers scaffold new blocks with a single command npm init @wordpress/block.

It is already available on NPM. It was published today as part of the next Gutenberg plugin release process that started on Monday.

Playwright vs Puppeteer

(Slack conversation)

Last week, Microsoft announced its new “Playwright” tool, which is very much like Puppeteer and created by many of its original contributors. The main draw here is that it supports multiple browsers, whereas we’ve always been limited to just Chrome using Puppeteer.

We discussed whether we should consider migration from Puppeteer to Playwright but we decide to postpone the decision for some time. The reason for that is the uncertainty about how those two projects evolve. The fact that the Puppeteer team has just released a new version that supports the Firefox browser makes it even more interesting. We plan to revisit this topic in the future.

#core-js, #javascript, #summary

JavaScript Chat Summary: January 21, 2020

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack transcript).

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

New “create-block” package

@gziolo has opened a pull request to propose a new “create-block” package, intended to be used by plugin authors to scaffold new blocks. This is the result of work which had been previewed during a previous meeting’s open floor.

Discussion points:

  • Separate package vs. part of the existing scripts package?
    • Needs to be separate to be usable as an npm init initializer.
    • We could decide later to add something to scripts which “proxies” commands to the separate package
  • Differences from the existing WP-CLI scaffold script?
    • Embraces build tooling, vs. intention of WP-CLI script to be run-and-done
    • Can be run outside a WordPress environment
  • Future goals

Action Items:

Open Floor

  • @epiqueras shared a problem which has surfaced in development of the block editor relating to values in inner blocks contextual to their ancestor blocks. He has worries about the performance impact of the current approaches, and has proposed an idea for a solution to improve the block API in a way which creates a shared context for block values.
  • @davilera raised an ongoing discussion regarding date function inconsistencies. This was also discussed during last week’s meeting. As an action item, he would like for a decision on the desired behavior and function signatures. We want to avoid backwards-incompatible changes. The pull request in its current form is sufficient for fixing an existing bug. After some discussion, a plan emerges that changes toward a more desirable API can and will be made within the current pull request without introducing breaking changes.

#core-js, #javascript

JavaScript Chat Summary: January 14, 2020

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack transcript). Thanks to @cbravobernal for compiling these notes.

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Date package

(Slack conversation)

@davilera mentions in the pull request issues a developer might face when using the date package and proposed how to solve them. Namely, source timezone, target timezone, and possible translation of the final date. People noticed that the package is not considering timezone.

Regarding PHP side, date_i18n() is remarked to be “illogical, incompatible with Unix timestamps, and in order to be deprecated”.

Action:

  • Identifying the minimum changes required to fix the original issue that PR tried to solve
  • Open a new issue where a discussion on if and how to refactor the package
  • Look at the current PHP implementation and trying to reconcile the two

Dropdown rendering with modals

(Slack conversation)

At first, the dropdown wasn’t rendering properly. But once the positioning was fixed, two more issues arose:

  • In a dropdown with multiple fields (such as, for instance, the one you get when using DateTimePicker), tabbing from one field to the other doesn’t work, as the focus moves away from the dropdown, back to the modal. This is an accessibility issue.
  • Dropdowns should be closed when one clicks outside of them. But this only works if you click outside of both the dropdown and the modal. Clicking on the modal doesn’t close the dropdown. Dunno what kind of issue this one is.

The mechanism that are affecting this behaviour is the SlotFill system 

@itsjonq says that the mechanism that are affecting this behaviour is the SlotFill system, and currently @hazdiego is working on an (unrelated) PR to start refactoring it:

https://github.com/WordPress/gutenberg/pull/19242

After a little discussion about how hard is to work on focus, modals, dropdowns…

Action:

Open Floor: Markdown linter

(Slack conversation)

@mkaz announce that he introduced a lint-md script that lints code blocks inside markdown. This uses a new .eslintrc-md.js config in scripts package to turn down some of the noise due to documentation being snippets of code.

Right now you need to run manually, we can fine tune and adjust the config before automating further. Try it out using: npm run lint-md [your-file] or if no file specified it runs across all markdown documents. 

Removing ES5 snippets is discussed also.

Action:

  • Try out the new script lint-md especially if writing or updating any markdown and source and we can see how it goes

Open Floor: NPM publishing

(Slack conversation)

@gziolo propose to grant npm permissions to @jonsurrell and Bernie Reiter so they could help with releases. Also talk about automate CHANGELOG file updates on the release day.

Action:

  • Grant NPM accesses (owned by @aduth)
  • Keep working on improving release workflow.

#core-js, #javascript

Javascript Chat Summary: Tuesday, December 17, 2019

Below is a of the discussion from this week’s JavaScript chat (agendaSlack Transcript)

Have a topic for discussion for the next meeting? Leave a suggested edit on the next chat agenda.

Next Javascript meeting is January 7th, 2020.

Because of a lot of people being AFK for their holidays we’ll skip the next two meetings.

Prettier

@aduth introduce the topic by saying:

There’s been quite a bit happening this past week, both in the comments of the revisions proposal post, and in the original pull request.

Post: https://make.wordpress.org/core/2019/12/09/proposed-javascript-coding-standards-revisions-for-prettier-compatibility/

Pull request: https://github.com/WordPress/gutenberg/pull/18048 

I think we’re in a position to make a decision on how to proceed here. From the feedback to the post, there are some general thoughts around improvements to the standard, but not any reluctance to Prettier specifically (quite the opposite, in fact!)

It would seem to me that most people are on board with this. Does anyone have any last-minute thoughts on this, or would it be fair to say we can move forward with adopting Prettier?

Based on the comments of the PR and the conversation in the chat, it seems we are in a position to merge this work.

@jsnajdr referred that the PR adds a format-js script to wp-scripts, and provides support for IDE integrations. Well-behaving Prettier editor integrations should pick up the config and the fork binary automatically.

@mkaz proposed a PR that documents these changes at https://github.com/WordPress/gutenberg/pull/19074.

The conversation went on @jsnajdr noted that the PR does not yet format the code, but we can easily format it with `wp-scripts format-js`.

@gziolo showed availability to collaborate/discuss with @jsnajdr how format-js will operate after the PR is merged.

@gziolo noted that having prettier code formatting will alow inline snapshots on the test cases https://jestjs.io/docs/en/snapshot-testing#inline-snapshots.

@aduth proposed the following action items:

  1. Merge @jsnajdr‘s pull request.
  2. Review, merge @mkaz developer tools documentation.
  3. Submit standards revisions changes.

After @jsnajdr‘s pull request is merged:

  1. Create a pull request to apply formatting to the entire codebase
  2. Explore options for automated formatting.

Participants agreed on the plan.

Block Scaffolding

@gziolo shared the following GIF showing block Scaffolding working:

Block Scaffolding Tool

@gziolo managed to implement ESNext template support with wp-scripts integration and is wondering if this scaffolding mechanism should be part of the Gutenberg repository.

Participants started discussing if this solution is part of the Gutenberg repository, what will happen to the current “official” scaffolding solution offered in WP-CLI. There are technical restrictions in making something equivalent to the solution @gziolo proposed on WP-CLI because WP-CLI should not depend on node.

@gziolo will continue iterating on the new scaffolding solution and, once tested, will import it into Gutenberg.

SVGR support in wp-scripts

@mkaz started the topic by saying:

I have a PR that adds SVG support to it which is a handy addition, but not sure if we want to add it without having the same support in core Gutenberg: https://github.com/WordPress/gutenberg/pull/18243 

For core blocks, we don’t inline SVG, we always code them, so this mechanism would not be used by core blocks, but it may be helpful for third party block developers.

@gziolo said Parcel 2 is heading in the direction of supporting CSS and SVG imports. @aduth said Parcel faces a similar challenge, and it may be a useful reference of how to address this problem.

#core-js, #javascript, #meeting-notes

JavaScript Chat Summary: December 10, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack Transcript).

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Follow-Up: JSDoc Guidelines

(Slack conversation, previous meeting summary)

Proposed JSDoc guidelines were merged since the last meeting. They are available in a readable format in its own section in the Coding Guidelines for Gutenberg.

Discussion:

In the previous week, we talked about having some new conventions to support what we need for the types effort summarized in the tracking issue on GitHub.

@aduth shared that as he’s been working through these tasks (PR for Priority Queue package), he’s already found a few other things that might be worth contemplating. He has a sense this could be an evolving standard or at least a need for some additional clarity in specific cases as noted in the agenda:

  • Explicit recommendation on types capitalization ({Object} vs. {object}).
  • @see vs. @link correctness – the current guidelines are mistaken in treating @link as a non-inline tag.

The eslint-plugin-jsdoc plugin we now use in Gutenberg has most of the “defaults” we had already been preferring for some time. The point is to make this explicit in the recommendations, as well.

Prettier

(Slack conversation)

There were proposed revisions to JavaScript Coding Standards for Prettier compatibility.

Discussion:

There have been a couple of comments on the post already. Still, they don’t seem to be directly relevant for what’s being considered in these revisions, and more to the quality of the document generally-speaking.

There is also this question of how we document the expected way of using Prettier. @aduth assumed there’s some need for editor integration or pre-commit script for these formattings to take effect. He also emphasized that when doing anything on that front, we should be preemptive about making this as minimally-disruptive as possible.

Actions:

  • Let’s wait until next Tuesday to make any “decisions” since one day of soliciting feedback might not be enough.

Date Library in Gutenberg

(Slack conversation)

@davilera tried to use wp.date and encountered an issue, which somebody had already reported. We need some feedback on the proposed PR from those who worked on dates more closely in the past. In the current shape, the library is currently hard to work with, and therefore developers are forced to implement workarounds.

Open Floor

Currently, there is only simple support for block scaffolding in WP-CLI that generates code that runs in the browser without the need for a build step. It’s documented here.

@gziolo ported this script to work with Node.js without the need to have an active installation of WordPress. The plan is to introduce the concept of templates and provide the default support for ESNext, JSX and all modern JavaScript tooling installed out of the box with the single command from CLI:

npm init wordpress-block
npm init wordpress-block
Npm package in action.

Bonus item:

https://react.christmas/

#core-js, #javascript

Proposed JavaScript Coding Standards Revisions for Prettier Compatibility

(The following standards revision proposal was drafted by @jsnajdr. Jarda maintains the wp-prettier Prettier fork and has been working to introduce it to the Gutenberg repository. You’re invited to provide feedback to this proposal in the comments below, or to join an upcoming JavaScript meeting in #core-js, where this will be discussed)


Across the JavaScript community, the Prettier code formatter has become immensely popular over that last three years since it was originally released. It automatically performs high-quality formatting of your JavaScript code: when you press Save, your code is instantly formatted. This removes a distraction for contributors who write or review code, and allows them to focus on the more valuable aspects of their work without having to discuss the JavaScript WordPress Coding Standards so often. That’s why we’d like to adopt it in the WordPress JavaScript code bases, too.

The official Prettier formatter is very opinionated and has very few options. The reasons are both technical and cultural. The complexity of the formatting algorithm would explode exponentially with too many options and their combinations, and a part of the project vision is to establish an unified JavaScript formatting standard.

The WordPress formatting standard has one major incompatibility with the Prettier convention: it requires spaces inside all kinds of parens — (){}[], inside template strings, JSX attributes and expressions, everywhere:

function Label( { text, icon } ) {
	if ( ! [ 'left', 'right' ].includes( icon ) ) {
		return null;
	}

	return (
		<label className={ `icon-${ icon }` }>
			{ text }
		</label>
	);
}

To teach this convention to Prettier, we had to create a fork that adds an extra option and modified the paren-formatting code, and publish it on NPM under the name wp-prettier (@wordpress/prettier would arguably be even better name!). At this moment, we’ve been using that fork for 2.5 years in the Calypso and Jetpack projects, have maintained and updated it over countless upstream releases, and are confident that we can recommend it to anyone who wants to format their JavaScript code the WordPress way.

In a Gutenberg pull request, we are proposing adopting the WordPress Prettier tool in the project.

After adding support for the WordPress style paren spacing, there remain several very minor cases where Prettier formats JavaScript code slightly differently from what the current WordPress JavaScript Coding Standards recommend. They don’t diverge from the essence and spirit of the WordPress coding standards. Further patching of Prettier would be, on our opinion, not worth the coding and maintenance effort. And in some cases is outright impossible, because the recommendation asks for human judgment that an algorithm cannot implement.

In this post, we propose several small changes of the coding standards that align them fully with the Prettier convention.

Formatting ternaries and binary ops

The standard says that when breaking a long statement, the “operator” should be at the end of line, and doesn’t distinguish between binary and ternary operators. But Prettier does. When breaking a binary operator, it indeed puts the operator at the end of line:

const result =
	partOne +
	PartTwo;

But the parts of a ternary operator are put on the start of the new line (after the indentation):

const result = isRtl
	? 'right'
	: 'left';

Also, the standard recommends that long “lines should be broken into logical groups if it improves readability”. That doesn’t happen with Prettier — it wraps the lines if and only if the line would be longer than maximum line length otherwise. We propose to remove that ambiguous and subjective formulation from the standard.

Wrapping chained n-ary operators

Another difference related to binary operators and the Multi-Line Statements section is that Prettier puts each operand on separate line, even the left side of an assignment. It doesn’t do the “fluid text wrap” style like this:

const result = a + b +
	c + d;

but this:

const result =
	a +
	b +
	c +
	d;

To address all these differences, we propose to reformulate the Multi-Line Statements section of the standards document as follows (the last paragraph about conditionals is unchanged):

Before:

When a statement is too long to fit on one line, line breaks must occur after an operator.

// Bad
var html = '<p>The sum of ' + a + ' and ' + b + ' plus ' + c
	+ ' is ' + ( a + b + c ) + '</p>';
 
// Good
var html = '<p>The sum of ' + a + ' and ' + b + ' plus ' + c +
	' is ' + ( a + b + c ) + '</p>';

Lines should be broken into logical groups if it improves readability, such as splitting each expression of a ternary operator onto its own line, even if both will fit on a single line.

// Acceptable
var baz = ( true === conditionalStatement() ) ? 'thing 1' : 'thing 2';
 
// Better
var baz = firstCondition( foo ) && secondCondition( bar ) ?
	qux( foo, bar ) :
	foo;

When a conditional is too long to fit on one line, each operand of a logical operator in the boolean expression must appear on its own line, indented one extra level from the opening and closing parentheses.

if (
	firstCondition() &&
	secondCondition() &&
	thirdCondition()
) {
	doStuff();
}

After:

When a statement with operators is too long to fit on one line and is broken into multiple lines, line breaks must occur after a binary operator. Each operand with the operator that follows it must be on a separate line.

// Bad
const html = '<p>The sum of ' + a + ' and ' + b + " plus " + c
	+ ' is ' + ( a + b + c ) + '</p>';
 
// Good
const html =
	'<p>The sum of ' +
	a +
	' and ' +
	b +
	' plus ' +
	c +
	' is ' +
	( a + b + c ) +
	'</p>';

On the other hand, when a long statement with a ternary operator is broken into multiple lines, the parts of the ternary operator should be after the line break:

// Bad
const baz = true === conditionalStatement() ?
	'thing 1' : 
	'thing 2';

// Good
const baz =
	true === conditionalStatement()
		? 'thing 1'
		: 'thing 2';

When a conditional is too long to fit on one line, each operand of a logical operator in the boolean expression must appear on its own line, indented one extra level from the opening and closing parentheses.

if (
	firstCondition() &&
	secondCondition() &&
	thirdCondition()
) {
	doStuff();
}

Chained method calls and context

The standard recommends that when one method in a chain “changes the context”, it should add an extra indentation:

elements
	.addClass( 'foo' )
	.children()
		.html( 'hello' )
	.end()
	.appendTo( 'body' );

But Prettier doesn’t know what the context is — it’s an ambiguous concept even for a human. So it indents everything equally:

elements
	.addClass( 'foo' )
	.children()
	.html( 'hello' )
	.end()
	.appendTo( 'body' );

It also adds one extra touch: if the initial identifier is just one or two characters long, it will keep the first method call on the same line:

el.addClass( 'foo' )
	.children()
	.html( 'hello' )
	.end()
	.appendTo( 'body' );

To address these differences, we propose to reformulate the Chained Method Calls section of the standards document as follows. The new formulation removes the requirements that can’t be reasonably implemented, focuses on the main points, i.e., breaking into multiple lines and consistent indentation, and modernizes the jQuery-based example to show more contemporary, functional JavaScript code.

Before:

When a chain of method calls is too long to fit on one line, there must be one call per line, with the first call on a separate line from the object the methods are called on. If the method changes the context, an extra level of indentation must be used.

elements
	.addClass( 'foo' )
	.children()
		.html( 'hello' )
	.end()
	.appendTo( 'body' );

After:

When a chain of method calls is too long to fit on one line, it must be broken into multiple lines where each line contains one call from the chain. All lines after the first must be indented by one tab.

findFocusable( context )
	.filter( isTabbableIndex )
	.map( mapElementToObjectTabbable )
	.sort( compareObjectTabbables )
	.map( mapObjectTabbableToElement );

#javascript, #standards