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

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