JavaScript chat summary, May 14th, 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: React Hooks for Data

Slack Conversation

We discussed an issue to introduce a useSelect React hook to the @wordpress/data package. The discussion focused on determining what the best API would be and a concern was raised to investigate the potential performance impact. We agreed it would be best to have a single useSelect function which allows to pass in a mapping callback for more complex conditional type use-cases involving multiple selectors/stores. We could create utility functions for simple cases.

Open floor: Node compatibility

The version of node-sass we use isn’t compatible with Node 12.x. A PR to update node-sass to a compatible version is now merged.

#core-js, #corejs, #javascript, #js

JavaScript chat summary, March 26th, 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.

Agenda: Building JavaScript

Slack Conversation

A post was published on the core Make blog titled Building JavaScript. It explains how to set up an ESNext development environment using the new WordPress scripts package. This provides an easy and standard method for building blocks and JavaScript heavy plugins.

The discussion continued towards a potential followup task: to offer a scaffolding package that would help to create your first block. This could then in turn be utilized by the wp scaffold command in WP CLI, to allow scaffolding blocks directly with WP CLI. The discussion continues on Github here: https://github.com/WordPress/gutenberg/issues/10629.

Agenda: Coding Guidelines

Slack Conversation

Coding guideline changes have been proposed for CSS naming and Experimental / Unstable JS API’s in Gutenberg. Feedback is welcome!

Agenda: Gutenberg Playground

Slack Conversation

A standalone Gutenberg playground environment has been merged. As we’re expanding the usage of Gutenberg outside of edit-post and also talking about cross-CMS usage and external usage (in the broad sense), we need a way to run the block editor in a context independent from WordPress Admin.

The playground allows us to test Gutenberg as a standalone editor. For example, we can use it to test that our components don’t rely on WP Admin styles to be present, that core blocks can be used without necessarily requiring a post object.

This is only a first step. The playground could evolve to contain examples of reusable components, and it could also serve as a contributor-tool to help developers discover API’s.

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

Javascript Chat Summary – October 23, 2018

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: Should wp.hooks support the special all hook?

Slack Conversation

In Gutenberg#8602 it is raised if we should add support for an all action in wp.hooks in order to match feature parity with the current PHP hooks system in WordPress core. While there were no real objections raised in the chat, pretty much everyone present agreed with this comment:

If it is primarily intended for debugging, then it might be worth exploring optimizations to avoid any impact in typical usage, e.g. monkey-patching runHooks when an all hook is added.

@aduth

Actions

  • No interest was expressed in the issue. If anyone wants to take it on, there wouldn’t be any objections either.

Agenda: Ways to optimize the package updating process

Slack Conversation

The process for updating packages needs to be optimized further. Right now any fix on a package has to follows the cumbersome flow of Gutenberg PR -> lerna release -> core ticket -> update package.json -> commit. We need to make this smoother.

This problem would probably not exist once everything is merged into a single monorepo hosted on git. But that doesn’t seem feasible just yet. Could we maybe mimic the advantage of having a monorepo a bit by getting more tooling into WordPress core and build straight from Github source? That would at least decouple publication of packages from being able to consume their changes in WordPress core development. 

It was raised by @gziolo that installing Gutenberg straight from Github with npm is not an option because Gutenberg consumes local packages which can’t be resolved by npm. The solution proposed is to take a similar approach to how Gutenberg packages are updated for Drupal.

This is done with an install script that simply clones Gutenberg into node_modules and builds the scripts in Gutenberg itself. While not a very elegant solution, this could work and drastically improve the process of keeping the packages updated.

Actions

  • @atimmer will work on a proof of concept.

Open floor: JS i18n

Slack Conversation

Good progress is being made on JavaScript language packs. 🎉 @herregroen is working together closely with @nerrad, @swissspidy and @ocean90 to land this. There seems to be a great deal of consensus and the work is nearing completion.

#corejs, #javascript

JavaScript Chat Summary – October 9th

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.

Preparing for WordPress 5.0

Action items

Annotations API in Gutenberg

  • The foundation work will be shipped in 4.0: The RichText package and the RichText structure.
  • A custom format API will be added. Likely for 4.1.
  • The annotations API should be built on top of this custom format API.

Action items

  • Continue the work on the custom format API targeted for 4.1: @iseulde
  • Coordinate with the Annotations API PR: @atimmer @iseulde

Generic Data Store API

The Data Module of Gutenberg is composed of two parts:

  • The Producer API: Registering stores, selectors, actions.
  • The Consumer API: Consuming selectors and actions in components and other scripts.

@coderkevin proposed to make the producer API less opinionated allowing custom stores implementations to leverage advanced use-cases for big applications/plugins like Calypso or WooCommerce while ensuring backward compatibility for the current implementation.

No blocker was raised on the Core side and the work should continue on the proposed PR.

Action items

#corejs, #javascript