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

JavaScript Chat Summary: December 3, 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: Types Checking

(Slack conversation, previous meeting summary)

A new tracking issue was created for modules types effort, including some rough guidelines toward the bottom of the comment.

@aduth shared a small pull request to demonstrate how this task can look for simpler modules, as a point of reference for others who might be interested in contributed.

Last week, there was some discussion about necessary changes for the automated documentation tool (“docgen”). A summary of these findings was shared on the corresponding issue.

Discussion:

  • @gziolo mentions that the effectiveness this process will need to be validated by other volunteers.
  • @aduth suggests a simple approach to testing types in a file by adding // @ts-check as a line at the top of a file.
  • @gziolo suggests it could be helpful to create a screencast to demonstrate the effort, referencing a similar example shared by @mkaz.

Action items:

  • Consider recording a screencast to demonstrate the effort of converting a package to be typed. (Tentatively owned by @mkaz)

JSDoc Standards

(Slack conversation)

Using JSDoc for types validation will force us to write better, more accurate JSDoc, which may require some new or updated guidelines (see current guidelines).

A few specific examples are mentioned:

  • Deemphasis of Backbone guidelines
  • Updates with respect to modernized syntaxes, files structure
  • TypeScript-specific JSDoc syntax extensions

Discussion:

  • Since these observations are limited to Gutenberg-exclusive use of ES2015 modules for files structuring and TypeScript tooling, it may make more sense for these supplementary guidelines to exist in the Gutenberg documentation.
  • Taking cues from the coding guidelines, the handbook standard can serve as a base upon which Gutenberg-specific recommendations can extend. Common guidelines should live in the JSDoc handbook, proposed for migration as appropriate similar to that done previously for Gutenberg JavaScript standards.

Actions:

  • Propose standards documentation for JSDoc syntax relevant for clarifying uncertainties in the types-checking effort. (Owned by @aduth)

#core-js, #javascript

JavaScript Chat Summary: November 26, 2019

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.

Open Floor: Types in Gutenberg

@aduth suggested to revisit the topic of improving types in Gutenberg. He mentions some work already done in URL module: https://github.com/WordPress/gutenberg/pull/17014

It was discussed to create a master issue with the progress of converting packages to use TypeScript validation based on JSDoc.

@gziolo fixed all ESLint warning related to the integration with the new plugin which combines JSDoc and ESLint, however this probably needs to be further investigated.

Action:

  • Create a tracking issue for module adoption of type checking
  • Push forward on effort to improve docgen ability to understand more of the TypeScript-specific syntax
  • Do some more conversions as demonstration

Open Floor: E2E Tests and Travis

Pushing a PR has been a bit of a chore recently with flakey tests, usually requiring a restart of a couple each time

For stability, it requires some diligence to investigate the underlying issues. Some improvements have been merged / proposed here:

@aduth have a few of these ideas in the Project Management Automation project board as well https://github.com/WordPress/gutenberg/projects/24

There was talk about documenting some of the common issues seen with E2E tests. Also to add a bot response with comments about the reasons of failing tests.

A CPU problem is mentioned: https://github.com/WordPress/gutenberg/pull/18770

Action: 

  • @noisysocks could look into some of this and write up findings/suggestions in an issue, not sure when though.

#core-js, #javascript

Javascript Chat Summary: Tuesday, November 5, 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 next week’s agenda.

Editor-specific .gitignore entries in Gutenberg

  • Context: https://github.com/WordPress/gutenberg/pull/18257#discussion_r342255694
    • Proposing to add a gitignore entry for VSCode’s “.vscode” local folder
  • Historically we’ve avoided editor-specific entries in the project’s gitignore to avoid opening pandora’s box (proliferation of ignore entries), but is this too rigid a guideline causing friction in new contributor onboarding?
  • Question: Should we allow more of these entries, and if so, which?

@gziolo said that he does not have a strong opinion on this item, but WordPress as a project is strict about it.

@mkaz also does not feels strong either way but said he would probably merge the PR because vscode its perhaps the largest and most popular editor.

@chancethedev shared his perspective as an instructor:

I often include vscode settings in my repos to make things easier for students when running workshops, so ignoring it globally won’t work for me. That said, I can just remember to remove it before I commit so it’s not a HUGE deal, I can just imagine folks slipping up often enough to where it’ll end up in commits from time-to-time and we’ll just have the conversation again.

@aduth and @adamsilverstein asked if the fact that WordPress os strict is written down somewhere?

@gziolo shared the following comment from https://core.trac.wordpress.org/ticket/34345:

IDE-specific .gitignore rules should not be present in a project. They should be managed in the user’s ~/.gitignore_global.

@gziolo added that it does not look like it is a written rule, as he was not able to find it in the docs. So, we can go both ways; we should document it to make it easy for contributors to update patches.

@nerrad said :

I lean towards adding the rule and just evaluating on a case-by-case basis.

It seems to be more dev friendly and avoids unnecessary noise in reviews.

@mkaz asked if there is any downside to adding the rule and @aduth answered:

I don’t think there’s a downside in-and-of-itself, more the slippery slope of how we make these decisions in the future without a well-defined approach.

@adamsilverstein suggested as action item working on some language for HOW we decide.

@mkaz and @gziolo suggested we add 3-5 top popular IDEs. @gziolo said we could also link to docs how to add an IDE to ~/.gitignore_global.

@aduth suggested, and @adamsilverstein supported that we can base it on “X% or greater” of some well-defined data, e.g., https://insights.stackoverflow.com/survey/2019#technology-_-most-popular-development-environments.

@chancethedev said he is joining the docs team specifically for Gutenberg docs, so he is happy to bring this up in the docs meeting today as well.

If you have any thoughts on this, please share them.

Bundling and loaders – extend core to allow SVG components

As part of the open floor, @mkaz introduced the topic by saying: 

For the open floor, I’m interested in the topic above regarding bundling and loaders – trying to extend core to allow SVG components.

Parcel sounds like an interesting option but looks like v2 is not out yet, so would need to wait

@aduth asked clarification on the background of this task and what is trying to be achieved by importing an SVG.

@mkas linked to the ticket https://github.com/WordPress/gutenberg/issues/14628 and said:

Right now the Social Links duplicates the SVG in CSS and PHP to work – we want to figure out some way to get it to a single .svg file

@aduth asked if it’d be feasible to manually shove the SVG into JSX. And asked if not an option to use something like <img src="icon.svg">.

@mkaz answered that the problem for the publishing view is KSES, and linking to images, one loses the ability to color them.

@aduth shared the main questions he thinks we should answer are “Should we do it, and if so, how?” and shared some thoughts :

  • I am conscious of the size inflation, though I think we need to be solving this problem anyways. Could be a way to prompt us to investigate better handling of “large” blocks (opening path for more complex blocks too, like reintroducing Code+SyntaxHighlighting).
  • I guess there is some issue with our build that the Webpack loader might not work? The Babel transform seems less ideal, but also workable.

@gziolo shared the following analysis of what creat react app did:

CRA experiments with Babel macros, but the blocker at the moment is cache invalidation. They had a very solid proposal to inline many types of files, including SVG with Babel macros https://github.com/facebook/create-react-app/issues/3722#issuecomment-458124126.

Macros struggle with the cache invalidation for the dependent files. See the comment in create-react-app https://github.com/facebook/create-react-app/commit/11737bc78676868e76ce5d0c04ddbb5c758d3908#diff-b1524f1e1ccabdb327a12f23b432b20bR13.

Related Babel issue which might resolve this issue in the future: https://github.com/babel/babel/issues/8497.

@mkaz said Parcel 2 sounds like a potential option for the future. Then, asked if we want to add SVGR support to wp-scripts without it in core Gutenberg, relevant PR https://github.com/WordPress/gutenberg/pull/18243. @gziolo answered that we use a custom config in Gutenberg, so it should be fine.

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

Announcing the new #core-css Slack channel

As a result of discussion in the last core dev chat we now have a brand new Slack channel dedicated to all things CSS!

Why do we need it/what is it for?

As a place to discuss CSS architecture and tooling, propose and maintain standards, ask questions and educate on best practices.

We have a ton of CSS in Core, and some of it is really old. Not that being old is in itself a bad thing 😁 but we might not need to support IE6 anymore, so some of those styles could use a bit of an upgrade. Having a dedicated CSS channel will help drive and focus efforts to improve our codebase for the benefit of all users and contributors.

In addition to that, we have a whole heap of CSS in Gutenberg, which, although more modern, needs care and maintenance too. 

There’s also something I perceive as a visibility issue. For instance, there’s a bit of a discussion going on in the GitHub repo around whether we should adopt CSS-in-JS tooling. It came up a few weeks ago in #core-js, and although to some extent it makes sense to discuss JS-based approaches in the JS channel, there’s a lot more at stake here than just the JS side of it. Not all contributors to the CSS parts of the codebase are JS devs, and not all of them are in the JS channel. It might be good to pull issues like that one into a CSS forum so we can get more diversity of input and opinions on them. 

Last but not least, CSS is transversal to Core and Gutenberg, and I hope a shared channel will help keep that wider scope in mind when we think of the changes we need to make on either side ❤️

Come and be part of the discussion in #core-css!

JavaScript chat summary, October 29nd, 2019

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

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

React prerelease channels

Slack Conversation

There was an announcement from the React team about official prerelease channels:

The long story short is they are promoting react@next prereleases and share some guidelines on how to test projects with the upcoming changes to their libraries. If you want to get involved and explore how the Gutenberg project could participate please comment on the corresponding issue.

Time of the meeting

Slack Conversation

Weekly meetings discuss JavaScript in the context of the WordPress ecosystem and we value the input from people working with JavaScript in WordPress. We wanted to survey people whether they would like to participate in the weekly chat if there was a different time?

As of today, we expect you’ll come to the meeting prepared to contribute your perspectives and help influence direction. You can also share in comments what would you expect from such meetings.

Testing components

Slack Conversation

There is an ongoing discussion about different approaches to testing UI components on GitHub. It isn’t a new topic. We have already considered removing enzyme in the past when some React APIs weren’t covered, but we gave up because of its wide usage.

We agreed that we can live with enzyme in old files following Code Refactoring guidelines, but we should plan to make it easier to contribute with tests when working on new features. @nerrad emphasized that it would be good to iron out what testing approach we want to recommend going forward. If anything the discussion in that issue highlights, we should include it in the Testing Overview documentation as the very first step.

@gziolo proposed we consider the E2E testing approach with the instance of Storybook as the testing environment given that it is a static site working like a single page application. @itsjonq shared that he’s done storybook E2E testing using Cypress in the past. It was something that could be automated by CI (Travis) and it worked great.

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

JavaScript chat summary, October 22nd, 2019

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

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

Agenda: Node LTS

Slack Conversation

Recently, Node 12 became the new LTS version for Node. A pull request to make WordPress scripts compatible with Node 12 was merged.

Agenda: Code style

Slack Conversation

A change to the JSDoc plugin triggered new ESLint warnings. These were fixed in a pull request: https://github.com/WordPress/gutenberg/pull/18025.

Another PR tries to bring WP Prettier into WP Scripts. WP Prettier is a Prettier fork that follows the WordPress code conventions that allows to easily reformat all of WordPress JavaScript but also enable other developers in the community who leverage WP scripts to do the same.

Agenda: Storybook

Slack Conversation

In September, Storybook was added to Gutenberg. There’s an issue open discussing next steps, which includes adding stories for all @wordpress/components and adding support for React Native components. @mkaz published a tutorial video on his blog on how to code a storybook story.

The following questions could be explored:

  • How can we enable plugin and theme developers to leverage storybook in their own workflows? It was suggested storybook could be added to WP scripts.
  • How can we integrate storybook into https://developer.wordpress.org/block-editor/? Storybook could be a replacement for the components reference.

A few concerns were raised with regard to using storybook on wordpress.org:

– How do we keep the WP dev site header?
– How do we avoid iframes (and include the header) to keep routing?
– How do we keep the READMEs (or some aspects of them) as there’s a lot of good info there?

It seems storybook allows for enough customization to be able to address these concerns. Some help from the meta team would be required.

Open floor: Card component

Slack Conversation

@itsjonq worked on a PR for a new Card component. There’s still some ongoing discussion about the introduction of css-in-js and Enzyme in that PR. Feedback appreciated!

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

Javascript Chat Summary: October 1, 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 next week’s agenda.

WordPress 5.3 progress

@gziolo announced that WordPress 5.3 release beta 2 is out. @gziolo asked if participants know if there any tasks left related to JavaScript core.

@jorgefilipecosta referred https://core.trac.wordpress.org/ticket/47527 as a small JS patch that should fix a bug in the media library. The patch should be ready and needs a review. A review there would be much appreciated.

@gziolo continued by saying it would be important to merge https://core.trac.wordpress.org/ticket/48154, which would simplify updating npm packages in WP core. But there is still this pending issue to address:

Where to put generated asset files to be consumed by PHP? At the moment they are generated in the folder, which in usual is exposed as client-side assets.

In case you have any ideas, please provide your insights on the ticket.

CSS support in wordpress/scripts

@gziolo introduced the subject by saying that it is something that we discussed some time ago in core-js chat. It’s tracked under https://github.com/WordPress/gutenberg/issues/14801, and it was primarily explored by @fabiankaegy in https://github.com/WordPress/gutenberg/pull/14847

Participants started discussing the challenge of CSS support in wordpress/scripts.

@gziolo shared some context:

In Gutenberg we don’t import CSS in JS files. Instead, we have a separate build step that converts the SCSS files into CSS files which are published to npm. There is some additional step performed by webpack, but I guess it’s mostly about ensuring the LTR version is produced as well.

@nerrad said:

I do think we should have @wordpress/scripts as a utility that builds CSS as well. But getting to something that addresses the various needs of those consuming it is the difficulty here.

@nerrad concluded that we need to decide the defaults for the CSS build system with ways to override them via CLI args.

@gziolo continued and said that ideally, we should be able to reuse as much as possible of what Gutenberg uses internally. This is the only way to ensure plugin/theme developers get all updates out of the box.

@gziolo questioned why developers default to importing CSS in JS file. @jsnajdr provided an answer to the question and then explained how the webpack runtime loads the assets. @gziolo found the mechanism interesting and said we should definitely explore alternatives in how we manage assets in WordPress core to better align with what JavaScript ecosystem offers these days. 

@gziolo continued the conversation and said that the mobile team is exploring how to build cross-platform UI components.

This is the PR https://github.com/WordPress/gutenberg/pull/17614 which explores styled-system and styled-components.

@pinarol said we want to reach a point where we can build blocks with a cross-platform components library which enables us to implement a block once and run it on both web/mobile.

This requires the mobile team to find a way to have a common styling system with the web, and since CSS is not supported by React Native we started to investigate styled-system and styled-components. @pinarol concluded by saying that this is a problem we want to solve as soon as possible.

@gziolo said that the approach used for multiplatform comments is directly related to work of making wordpress/scripts support CSS.

Storybook

@gziolo announced that we are considering adding Storybook to help with the development of UI components.

It is possible to leave feedback on the PR’s that propose this addition https://github.com/WordPress/gutenberg/pull/17475 and https://github.com/WordPress/gutenberg/pull/17173. They are alternative versions for a similar goal.

@ajitbohra also implemented a similar solution outside of the Gutenberg repository and said he would love to consolidate efforts.

Custom element interoperability

@flixos90 proposed a PR that includes CustomElement interoperability for block types

If you care about the support for web components in Gutenberg, give the PR https://github.com/WordPress/gutenberg/pull/17649 a spin and help to land it.

In case, you have any insights or suggestions please share them on the PR.

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

JavaScript chat summary, September 24th, 2019

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

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

New JavaScript APIs and support for previous versions of WordPress

Discussion: @adamsilverstein suggested that we add a developer guide section to explain how to write plugins that use newly introduced JavaScript APIs to work with older versions of WordPress. The biggest challenge is how to approach APIs which are exposed by new modules available under the wp global namespace.

We encourage plugin developers to share their strategies in the comments so we could work on the official recommendations on how to tackle this issue.

We also agreed that a good start would be to enforce using the @since pragma in JSDoc comments for all public APIs present in JavaScript code. This is something that is taken for granted in PHP codebase.

Action items:

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