JavaScript Chat Summary – December 18th

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 agenda (January 8th).

Next meeting

This is the last meeting of the year. The next meeting will be held on January 8.

WordCamp US contributor day

A lot of fruitful contributions and discussions happened during the WCUS contributor day:

  • @herregroen made some progress toward improvements in how JSDoc are extracted and surfaced to developer documentation. More info in this slack thread and core ticket.
  • A Pull Request bringing aXe accessibility e2e testing in the Gutenberg repository has been created. The folks at Deque published a blog post about their takeaways.

Node 10.x LTS

The new versions of Gutenberg packages now require Node 10 or newer. This is to align with our stated support to follow the LTS release cycle of Node.

ESlint Package

The first version of the @wordpress/eslint-plugin package including recommended WordPress ESLint configuration has been published. A post detailing all the guidelines bundled in this package has been shared.

Action items:

  • Clarify in the docs and the package.json that the package requires eslint-plugin-react, eslint-plugin-jsx-a11y and eslint as peer dependencies.

JavaScript Documentation effort

There is an agreement that we need a bigger documentation effort to clarify some misunderstanding about the internals of Gutenberg.

Related:

  • If you have some technical knowledge and are interested in helping the documentation efforts, please have a look at this call for contributors.
  • Yoast is working on some extensibility APIs docs.

Documentation will be discussed further on the next meeting.

Open floor

#core-js, #javascript

Proposed Revisions to JavaScript Coding Standards

Coding standards have been a recurring topic during the JavaScript Weekly Chats, most recently in the December 4th, November 27th, July 31st, July 24th, and July 17th meetings.

As a result of these conversations and in the observed emergence of patterns during the development of Gutenberg, a number of revisions to the JavaScript Coding Standards have been considered for proposal. This post serves as an outline of these proposals, presented here for wider consideration.

These proposed changes do not intend to serve as a radical departure in style, but rather to clarify ambiguities, resolve inconsistencies, and reduce the number of exceptions present in the standards.

You can try these coding standards using the newly-published ESLint configurations . Note that the ESLint plugin requires ESLint v5 or later, and eslint-plugin-reactand eslint-plugin-jsx-a11y must be installed in your development environment. Refer to the ESLint User Guide for more information.

Comments

Proposed Change: The use of /* for multi-line comments is not prescribed; it is now acceptable to use // for multi-line comments. An additional note about JSDoc /** should be included and refer the reader to the JavaScript Documentation Standards.

Before:

Single line comments:

someStatement();

// Explanation of something complex on the next line
$( 'p' ).doSomething();

Multi-line comments should be used for long comments, see also the JavaScript Documentation Standards:

/*
 * This is a comment that is long enough to warrant being stretched
 * over the span of multiple lines.
 */

After:

someStatement();

// Explanation of something complex on the next line
$( 'p' ).doSomething();

// This is a comment that is long enough to warrant being stretched
// over the span of multiple lines.

JSDoc comments should use the /** multi-line comment opening. Refer to the JavaScript Documentation Standards for more information.

Spacing

Proposed Change: Remove all spacing exceptions for object and array property access. This is a further iteration upon a previous revision which had removed exceptions for function arguments.

Before:

Always include extra spaces around elements and arguments:

array = [ a, b ];

foo( arg );

foo( 'string', object );

foo( options, object[ property ] );

foo( node, 'property', 2 );

Exceptions:

// For consistency with our PHP standards, do not include a space around
// string literals or integers used as key values in array notation:
prop = object['default'];
firstArrayElement = arr[0];

After:

Always include extra spaces around elements and arguments:

array = [ a, b ];

foo( arg );

foo( 'string', object );

foo( options, object[ property ] );

foo( node, 'property', 2 );

prop = object[ 'default' ];

firstArrayElement = arr[ 0 ];

“Yoda” Conditions

Proposed Change: This guideline will be removed from the coding standards. While it is still an option for developers to use this pattern, it will not be enforced one way or the other.

Before:

“Yoda” Conditions

For consistency with the PHP code standards, whenever you are comparing an object to a string, boolean, integer, or other constant or literal, the variable should always be put on the right hand side, and the constant or literal put on the left.

if ( true === myCondition ) {
// Do stuff
}

“A little bizarre, it is, to read. Get used to it, you will.”

After:

(N/A – The section is to be removed)

Equality

Proposed Change: There will be no exceptions for using strict equality === operator. The previous exception for == null comparison should be avoided, preferring in its place the equivalent strict equality comparisons on === undefined and === null.

Before:

Strict equality checks (===) must be used in favor of abstract equality checks (==). The only exception is when checking for both undefined and null by way of null.

After:

Strict equality checks (===) must be used in favor of abstract equality checks (==).

Multi-Line Conditions

Proposed Change: If a condition is short enough to fit in a line, it should be occupy a single line. Otherwise, the condition should be split one-per-line, with the opening and closing parentheses each on their own lines.

Before:

When a conditional is too long to fit on one line, successive lines must be indented one extra level to distinguish them from the body.

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

After:

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();
}

Naming Conventions

Proposed Change: The additional naming conventions adopted into Gutenberg will be inherited into the WordPress JavaScript Coding Standards.

Namely, this includes additional consideration for:

  • Abbreviations and acronyms
  • Class construct (and @wordpress/element Components)
  • Constants

Before:

Variable and function names should be full words, using camel case with a lowercase first letter. This is an area where this standard differs from the WordPress PHP coding standards.

Constructors intended for use with new should have a capital first letter (UpperCamelCase).

Names should be descriptive, but not excessively so. Exceptions are allowed for iterators, such as the use of i to represent the index in a loop.

After:

Variable and function names should be full words, using camel case with a lowercase first letter. This is an area where this standard differs from the WordPress PHP coding standards.

Names should be descriptive, but not excessively so. Exceptions are allowed for iterators, such as the use of i to represent the index in a loop.

Abbreviations and Acronyms

Abbreviations must be written as camel case, with an initial capitalized letter followed by lowercase letters.

Acronyms must be written with each of its composing letters capitalized. This is intended to reflect that each letter of the acronym is a proper word in its expanded form.

If an abbreviation or an acronym occurs at the start of a variable name, it must be written to respect the camelcase naming rules covering the first letter of a variable or class definition. For variable assignment, this means writing the abbreviation entirely as lowercase. For class definitions, its initial letter should be capitalized.

// "Id" is an abbreviation of "Identifier":
const userId = 1;

// "DOM" is an acronym of "Document Object Model":
const currentDOMDocument = window.document;

// Acronyms and abbreviations at the start of a variable name are consistent
// with camelcase rules covering the first letter of a variable or class.
const domDocument = window.document;
class DOMDocument {}
class IdCollection {}

Class Definitions

Constructors intended for use with new should have a capital first letter (UpperCamelCase).

A class definition must use the UpperCamelCase convention, regardless of whether it is intended to be used with new construction.

class Earth {
	static addHuman( human ) {
		Earth.humans.push( human );
	}

	static getHumans() {
		return Earth.humans;
	}
}

Earth.humans = [];

All @wordpress/element Components, including stateless function components, should be named using Class Definition naming rules, both for consistency and to reflect the fact that a component may need to be transitioned from a function to a class without breaking compatibility.

Constants

An exception to camel case is made for constant values which are never intended to be reassigned or mutated. Such variables must use the SCREAMING_SNAKE_CASE convention.

In almost all cases, a constant should be defined in the top-most scope of a file. It is important to note that JavaScript’s const assignment is conceptually more limited than what is implied here, where a value assigned by const in JavaScript can in-fact be mutated, and is only protected against reassignment. A constant as defined in these coding guidelines applies only to values which are expected to never change, and is a strategy for developers to communicate intent moreso than it is a technical restriction.

Trailing Commas

Proposed Change: Trailing commas are to be enforced for arrays and objects whose members are enumerated across multiple lines. This should be incorporated into existing sections for “Objects” and “Arrays”.

Before:

Objects

Object declarations can be made on a single line if they are short (remember the line length guidelines). When an object declaration is too long to fit on one line, there must be one property per line. Property names only need to be quoted if they are reserved words or contain special characters:
// Preferred
var map = {
	ready: 9,
	when: 4,
	'you are': 15
};

// Acceptable for small objects
var map = { ready: 9, when: 4, 'you are': 15 };

// Bad
var map = { ready: 9,
	when: 4, 'you are': 15 };

After:

Object and Array Members

Objects and arrays can be declared on a single line if they are short (remember the line length guidelines). When an object or array is too long to fit on one line, each member must be placed on its own line and each line ended by a comma.

Object property names only need to be quoted if they are reserved words or contain special characters:

// Preferred
var obj = {
	ready: 9,
	when: 4,
	'you are': 15,
};
var arr = [
	9,
	4,
	15,
];

// Acceptable for small objects and arrays
var obj = { ready: 9, when: 4, 'you are': 15 };
var arr = [ 9, 4, 15 ];

// Bad
var obj = { ready: 9,
	when: 4, 'you are': 15 };
var arr = [ 9,
	4, 15 ];

Assignments and Globals

Proposed Change: For code written in ES2015+ using const and let, additional guidelines should be included to reflect differences in block scoping semantics. A new section “Declaring Variables with const and let” should be added before “Declaring Variables with var“.

After:

Declaring Variables with const and let

For code written using ES2015 or newer, const and let should always be used in place of var. A declaration should use const unless its value will be reassigned, in which case let is appropriate.

Unlike var, it is not necessary to declare all variables at the top of a function.

#javascript

WordPress 5.0.2 RC2


The second release candidate package for 5.0.2 is now available for testing. Please help test the release candidate version to ensure the version works as expected. After activating the WordPress Beta Tester plugin, check that the “Point release nightlies” option is selected before updating.

WordPress 5.0.2 will be released on December 19. It contains 28 core bug fixes, as well as the bug fixes and performance improvements from the recent Gutenberg 4.7 release. This release candidate fixes 3 additional bugs since the previous RC.

Thank you to everyone who’s already helped through testing, bug reporting, submitting patches, as well as all of the feedback we’ve received since WordPress 5.0 was released. 🥰

#5-0, #release

X-post: Iterating our design workflow keywords in trac

X-comment from +make.wordpress.org/design: Comment on Iterating our design workflow keywords in trac

Multisite agenda: December 18

This is the agenda for the weekly office hours meeting on Tuesday, December 18th, 2018 at 17:00 UTC in #core-multisite.

As mentioned in #core-multisite last week, it’s been a while since the last organized multisite office hours. Let’s use this as an opportunity to regroup and determine what’s next in 2019. In particular, these topics will be covered:

  • Status of progress made in 2018. Nothing has shipped officially yet, but a full recap of all changes currently in trunk needs to be written so that the current state can be communicated.
  • Expectations for 2019. What reasonably matches (and doesn’t match) the overall WordPress project focus for the next year.
  • Office hours in 2019. What time, how frequently, who is leading them.

In addition to those general topics, @flixos90 would like to reserve 10-20 minutes to chat about the multisite integrations of WSOD protection in Servehappy. The core ticket is #44458 and patches are also applied as a pull request on GitHub.

Please join the chat if you’re interested in one of the topics. In case you cannot make the respective meeting, we will be working on publishing a recap post afterwards. If you have some thoughts beforehand or would like something related to be part of the agenda, feel free to share your ideas in the comments for this post. See you in the chat!

#agenda, #multisite, #networks-sites

Status Update: Porting Widgets to Blocks

Per 9 Projects for 2019, all widgets will be ported over to Gutenberg blocks. I went through and audited how close we are to completing this goal:

✅ Completed

  • Audio [2299]
  • Archives [7949]
  • Categories [2102]
  • Custom HTML [1391]
  • Image [379]
  • Latest Comments [7941]
  • Latest Posts [870]
  • Text
  • Video

✏️ Work in Progress

🖼 Has Design

  • Calendar [1462]
  • Classic Widgets [4770]
    • Any existing widget will work by using the Classic Widget block.
  • Navigation Menu [1466]
    • This has a bunch of design ideas, but not a finished design. This block design is still a WIP.
    • Note: This is also its own 2019 project.

Additionally, the following completed widget blocks have v2 designs:

  • Archives [1464]
  • Recent Comments [1792]
  • Recent Posts [1594]

⌨️ Has PR

🙅🏽‍♀️ Deprecate?

There’s a couple widgets that I personally think can be deprecated:

  • Meta: Feels anachronistic and out-of-place in modern WordPress.
  • Pages: Should be replaceable with a navigation menu block.

Next Steps

Given this list, I think our top priorities are:

  1. Reopen, finish up, and merge existing widget block PRs.
  2. Create a PR for Calendar — maybe two: one following the original design, and one following the more complex v2. The original can likely be completed and merged quickly, which would put us in a great place in terms of widget support.
  3. Review the Classic Widget block design to ensure it matches current Gutenberg patterns, and create a PR.
  4. Create v2 PRs for Archives, Calendar, Recent Comments, and Recent Posts. Having a working PR can help us establish whether or not the designs are feasible, and a better experience.

Navigation Menu, as a broader block that extends beyond just widgets, should be tackled separately from this effort.

@karmatosed has created a new GitHub project we can use to track progress: https://github.com/WordPress/gutenberg/projects/20.

#blocks, #gutenberg, #widgets

WordPress 5.0.2 Release Candidate

The release candidate package for 5.0.2 is now available for testing. Please help test the release candidate version to ensure the version works as expected.

WordPress 5.0.2 will be released on December 19. It contains 26 core bug fixes, as well as the bug fixes and performance improvements from the recent Gutenberg 4.7 release.

Thank you to everyone who’s already helped through testing, bug reporting, submitting patches, as well as all of the feedback we’ve received since WordPress 5.0 was released. 💖

#5-0, #release

5.0.2: Editor Performance and Bug Fixes

With 5.0 released to the world, attention is now placed on preparing the follow up minor releases. The first one, scheduled for December 19th, focuses on performance improvements — particularly around typing with many blocks present on the page — and bug fixes.

The cumulated performance gains are around 330% faster for a post with 200 blocks. This might be even bigger for certain setups and plugin configurations — seeing the same test post be 540% faster with Yoast, for example.

The Gutenberg update can already be tested in the 4.7 plugin release and will be part of the upcoming 5.0.2 beta.

Performance 💨

Bug Fixes 🐛

Tests

#core-editor, #editor, #gutenberg

PHP Meeting Recap – December 3rd

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

  • @drewapicture announced that he’d start working on a proposal to add modern PHP best practices to the core handbook at WCUS contributor day.
  • The discussion about feature flags from the previous week was picked up again, particularly regarding the trade-offs of relying on a (network) option vs relying on a constant or environment variable.
    • Since some of the processes to be tested are executed very early in the WordPress bootstrap process, a variable that can be set in wp-config.php or earlier should be used. There possibly could be a wrapper function to access that value, including a filter that would allow adjusting the constant value dynamically by code that would run later.
    • WP-CLI could also be used to “more dynamically” set the constants.
    • It was mostly agreed that the Beta Tester plugin should somehow incorporate the feature flags functionality, in favor of core, at least initially.
    • Eventually, it was summarized that the topic should get picked up again later, as the WSOD protection mechanism (see #44458) is not blocked by this and should move forward.
  • Further conversations on the current state of the project will happen at WCUS, with the results being published in a recap. The meeting on December 10th is cancelled because of WCUS and related travel.

Post-WCUS Update

  • As mentioned during the State of the Word, WordPress core aims to raise the minimum required PHP version to 5.6 by April 2019, and to 7 by end of 2019 – a great success for the ecosystem and the Servehappy initiative.
  • A conversation between members of the core, community and hosting teams happened during contributor day, planning the steps ahead for both Servehappy and the overall Site Health project that it is part of. A detailed summary of this will be published separately.
  • The goal for the initial parts of Servehappy is to release them ahead of the PHP version bump, likely as part of WordPress 5.1. Due to the intended version bump, the core notice should be displayed on all PHP versions below 5.6, contrary to the originally intended idea of only targeting 5.2 initially.

Next week’s meeting

#core-php, #php, #servehappy, #summary

Dev Chat Summary: December 12th

Dev Chat Scheduling

As many folks will be away over the Christmas/New Year period, the next few meetings will be as follows:

  • December 19: Normal meeting.
  • December 26: Normal meeting will not be happening. There are likely to be core folks around to answer questions for an open floor session.
  • January 2: Normal meeting.

5.0.2 Schedule and Scope

Please note that WordPress 5.0.1 has just been released, so any previous mentions of scope or schedule for WordPress 5.0.1 should now be read as applying to WordPress 5.0.2.

WordPress 5.0.2 is intended to be released two weeks after WordPress 5.0, which would make the release date December 20. To give a little more space before the Christmas/New Year holiday period, I’ve proposed that it be released December 19.

Milestone Dates

  • Release Candidate 1: December 14, 2018
  • Release Candidate 2 (if needed): December 17, 2018.
  • General Release: December 19, 2018.

The following items are in scope for the 5.0.2 release:

  • Gutenberg 4.7 was released today, the fixes in this plugin release will also be in WordPress 5.0.2.
  • Twenty Nineteen bugs and visual issues.
  • There are a few PHP 7.3 compatibility fixes to be made.

Any other tickets currently milestoned for 5.0.2 will be considered on a case-by-case basis, priority will be given to tickets with patches, testing, screenshots, and any other relevant information to show that they’re ready to land immediately.

5.1 Schedule and Scope

As there are already over 200 tickets fixed in WordPress 5.1, I’d like to propose that WordPress 5.1 has a relatively short release cycle.

Milestone Dates

  • Beta 1: January 10, 2019
  • Release Candidate 1: February 7, 2019
  • General Release: February 21, 2019

A key point from the WordPress 5.0 cycle was that it demonstrated the value of having a hard feature freeze at beta 1, as well as string freezes and strict bug fixing policies during the release candidate phase. With that in mind, I’d like to propose that we retain these policies for the WordPress 5.1 cycle.

The tickets already fixed in WordPress 5.1 need to be reviewed, to ensure they’re all stable for release in this cycle.

Apart from that, the PHP upgrade warnings and the White Screen of Death protection from the Site Health Check project are currently the only uncommitted features scheduled for WordPress 5.1. The PHP upgrade warnings are currently soft warnings, ahead of the minimum PHP version bump proposed for April 2019.

@matt will be continuing his role as release lead into WordPress 5.1. Any other feature proposals will need to be approved by him.

Please leave feedback on this post, so the scope and schedule can be confirmed in the next day or two.

Focus and Component Updates

REST API

The REST API group will be re-opening discussion around authentication solutions. They’ll be posting further information about this project on make/core.

Core JS

The Core JS group didn’t meet this week, due to many folks travelling home from WCUS. They’ll be resuming normal meetings next week.

Core Themes

The current themes focus is on triaging Twenty Nineteen issues for 5.0.2, as well as preparing to move activity from GitHub into Trac. This move will likely happen immediately after 5.0.2.

#5-0-1, #5-0, #5-1, #core, #dev-chat