Javascript Chat Summary: August 13, 2019

Below is a 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 next week’s agenda.

Agenda: Shared Core Dependencies


The Google Doc Agenda has much of the content of what was discussed, but as a summary:

Package/Bundle size for assets is a significant concern for frontend use as WordPress continues to expand javascript as a first class citizen in its ecosystem. Some examples where this surfaces are:

  • using wp.element on the frontend. It has a dependency on lodash which adds weight to page load.
  • implementing various components or blocks on the frontend (wp.components itself has significant size).

Some potential ways to resolve/improve this for not only frontend but also admin are:

Load externals via CDN.

Externals such as react, react-dom, lodash etc could still be registered but the source would be from CDN. The advantage here is with WP’s wide reach, it’s much more likely that client browsers will have cached the asset for visitors to WP sites. Currently that’s less likely because of every site hosting it’s own assets by default.

Action: @adamsilverstein is going to raise this in the hosting meeting to get feedback from there.

Size of packages.

Here, the focus is on how big are we willing to allow various bundles to get? For instance wp.components is 553kB minified.

  • should we start thinking about setting some comfortable limits on how big we allow bundles to get? (tools like bundlesize could help with that)
  • what ways can bundles be further reduced in size (example of @wordpress/server-side-render being extracted into it’s own package) – audit packages and see what other extractions/groupings can be done?
  • WP core supports script-aliases (enqueuing wp-components could actually enqueue X different files behind the scenes, all populating the wp global).
  • Reduce external dependencies: Example is lodash dependency removal from @wordpress/element. Much of the functionality of lodash can be implemented via native js.


  • It’d be good if those interested in javascript in WordPress start thinking through some of what’s been discussed in this item and contribute some proposals on how to improve things.
  • On the last item, removing lodash dependency from WordPress packages has been proposed. It’d be nice to get a decision on moving forward there. Please contribute your thoughts to the issue!

Agenda: Lazy Loading of Images and Frames

Slack | Trac | lazysizes library | Native lazy-loading for the web article

The discussion here centered around whether lazy loading of images is something that should be implemented in WordPress core and some initial ideas on what would be involved in doing that. Some highlights of the discussion (though no concrete decision was made):

  • opt-in for now
  • possibly implemented via add-theme-support
  • include for wp-admin as well (eg. Media Library)


  • continue to contribute to the trac ticket. Possibly explore landing something for wp-admin first.

Open Floor

  • @joyously asked about the status/possibility of updating jQuery (see trac ticket (slack convo). Nothing concrete from the discussion. Current blockers are the difficulty in resolving issues with the update and conflicts/failures with the customizer and media. Also reluctance exists to invest effort in something that may become obsolete due to changes in framework used (moving to more react heavy admin). Joy did note that the biggest problem existing right now are the flags raised by security scanners detecting the version number (author note: vulnerabilities in jQuery bundled with core are patched, but security scanners still detect it as a vulnerable version).

#javascript, #meeting-notes

Javascript Chat Summary: August 6, 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.

Publishing npm packages

@gziolo announced that we published to npm new versions of all WordPress packages.

@gziolo added that we didn’t publish to npm in the last two months, although we could do it given that Gutenberg release happens every other week.

@gziolo asked for thoughts on how we can improve the process overall, and maybe automate it.

People noticed that the current process involves lots of manual work.

Some options were discussed, @gziolo noted that he does not think we can publish to npm from CI since we require all accounts to use 2FA.

@nerrad suggested we can do an iteration on the automation scripts @youknowriad build andding something like `commander deploy:trunk`.

@jorgefilipecosta noted that an automation tool will face a problem when merging Gutenberg PHP changes to core.

@youknowriad agreed and added that the PHP could never be automated. Both repositories have different PHP setups/requirements (one is a plugin on top of the other). But noted PHP is the small part of the work, and a helper tool could compare versions and say, we have these PHP changes, don’t forget to backport them.

In continuation of the PHP code updates conversation, @omarreiss added that:

Normally I would solve a problem like this by treating the Gutenberg PHP as a dependency of WordPress core. We could install that and keep that up to date by using composer. There is a ticket open for managing external PHP dependencies with the composer, but it’s not moving very fast, see If that were the case, we could register an alternative initializer/autoloader when Gutenberg is active, and we would be done. The only problem is that the PHP in Gutenberg isn’t well isolated. To really solve this problem, the PHP in Gutenberg needs to start behaving like a more clean dependency, and we should centralize its initialization. This would require some refactoring. I wouldn’t mind exploring this approach, but I’d like some blessings on the direction from people like @pento and @jorbin first.

@youknowriad noted that @omarreiss suggestion means re-architecture WordPress to be built using PHP modules (same as we do with JS). @omarreiss agreed and said that was the reason why he does not want to explore further without some openness to the direction.

Help build an automation tool

@gziolo asked if we have someone willing to explore how we can automate as much as possible to make the process on WordPress core side less time-consuming and error-prone?

@dsifford said that he does not want to get distracted from the other work he is currently doing (jsdoc improvements), but we can consider him a fallback in case no one takes up this task.

If this task is something that interests you, and you want to expand knowledge about scripting and automation, please tell us about your interest in the comments.

Gutenberg Examples repository

@gziolo opened the topic by saying that we still maintain a repository with Gutenberg examples (, and asked:

What’s the process like for such repositories with merging changes? I have PR opened, and I have no idea what to do next:

@netweb answered:

What I typically see is another Gutenberg core dev will to a drive-by review, approve and merge. So, nothing official.

The conversation continued and aborded specific subjects related to the PR @gziolo referred.

@gziolo concluded that although this repository isn’t as popular as others, we should still go through review/approve process as it’s useful.

Other subjects

@dsifford asked for reviews on PR – “Add eslint-plugin-jsdoc for better JSDoc linting“.

People talked a little bit about that PR and chat participants provided some feedback.

Meanwhile, after the chat, the PR got a review, was approved and merged.

#core-js, #javascript, #meeting, #summary

Javascript Chat Summary: July 30, 2019

Below is a 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 next week’s agenda.


Slack Conversation

@gziolo substitutes @aduth as the chat’s co-host in the next 3 months while he enjoys well deserved time off. It was a good opportunity to refresh the group of Note Takers. Kudos to @cbravobernal for volunteering to help with summary posts like this one. For those who still would like to get involved let us know. Here is the document which explains in-depth what does it entail.

Type Definitions

Slack Conversation

First, there is some exciting news to share for those who use TypeScript in their workflows. The last of the DefinitelyTyped submissions for package type definitions has been merged. Great work @dsifford on the related PR.

We also discussed possible next steps in terms of improving the auto-generated documentation. There was a general agreement that we should seek ways to improve the current approach with JSDoc comments before we jump into deep integration with TypeScript.

Action items

  • Replace the existing JSDoc ESLint rules with eslint-plugin-jsdoc (GitHub issue).
  • Improve existing JSDoc comments as we enable TypeScript checking gradually for all packages. This task should be coordinated with the tracking issue on GitHub.

#core-js, #javascript

Javascript Chat Summary: July 9, 2019

Below is a 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 next week’s agenda.

Agenda: Documentation Standards – @yield

Current Standards | Github Example | JsDocs| Slack

Some discussion around documentation standards for the @yield JSDoc tag:

Should the @yield JSDoc tag (used for generator functions) be considered as part of a grouping with @return?

There seemed to be consensus to consider @yield usage to be a separate grouping (newline between other “groups”, only aligned to itself).

Action: @aduth will update the documentations page to address the standards.

Open Floor

  • @nerrad requested eyes on (slack)

#core-js, #javascript

JavaScript chat summary, June 25th + July 2nd, 2019

Below is a summary of the discussion from the JavaScript chat of the last two weeks (agenda June 25thSlack Transcript June 25th, agenda July 2ndSlack Transcript July 2nd)

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

Agenda: E2E Test infrastructure for Core

Slack Conversation June 25th

A ticket was created by @youknowriad which seeks to incorporate Gutenberg’s end-to-end test setup into WordPress core: The patch has been reviewed by multiple members of the Core JS team and was eventually committed. @youknowriad wrote a devnote here:

Agenda: E2E Tests – next steps

Slack Conversation July 2nd

With the e2e framework now in core, we can start adding testcases. A few good next steps were raised:

  • Encouraging people to write tests, anytime we notice a regression or an important feature. Some coordination would probably help. Who could help lead/organize it?
  • Try to run the Gutenberg e2e tests (maybe not all of them) in Core’s CI as well. This would allow upgrading the npm packages from Gutenberg in Core with more confidence.
  • Extending the framework to be able to run tests across PHP versions could definitely be helpful for smoke testing pages, checking there are no warnings, etc.
  • Improving the documentation with regard to e2e test would also be valuable.

These points could best be raised in Devchat as well, as they transcend the realm of Core JS.

Agenda: Build all Core JS with WebPack

Slack Conversation

A new patch was uploaded by @herregroen to build all core JavaScript with Webpack: Building all JS in core with WebPack means we can have a single consistent build process for all JS, rather than having different build tools for Gutenberg and the media library versus everything else. It also allows us to start reusing WordPress packages in the JavaScript that is already present in core. Some more review and testing is needed.

Open Floor: Request for feedback

Slack Conversation

There is some exploration going on around possible solutions for interpolating React elements in strings in this Gutenberg issue: @nerrad has requested some feedback to some recent considerations he’d proposed in that issue. Input is welcome!

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

JavaScript Chat Summary, June 11, 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.

Component Props Documentation

Slack Conversation

Question: How can we eliminate human error from components documentation?

Context: @dsifford‘s recent pull requests can sort of speak for themselves so far as demonstrating the current inaccuracies in components documentation. He’s discovered them while working on type definitions added to DefinitelyTyped for @wordpress/* packages and he’s tracking progress on Trello board. If anyone is interested in helping the effort let us know.

Options discussed:

  • Improve current JSDoc documentation.
  • Add support for React.PropTypes.
  • Introduce TypeScript.

Action items:

Open Floor

Slack Conversation

Some of us are traveling to WordCamp Europe next week, so we agreed to cancel the meeting planned for next Tuesday and pick up again on June, 25th.

#core-js, #design, #javascript

Introducing useDispatch and useSelect

Coming soon via the pending Gutenberg 5.9 plugin release (and the subsequent @wordpress/data package release) are two new apis to use in implementations interacting with the api. useSelect and useDispatch are custom React hooks that enable a more declarative interface to registered stores in the registry. In this post I’m going to try to give some highlights of these new apis.

What happens to withSelect and withDispatch?

The short answer is, “nothing”! withSelect and withDispatch are still usable and are not being deprecated. In fact, under the hood they have both been refactored to use hooks also.

There’s no pressing need to retire these interfaces so you can reliably keep on using them!


React hooks are becoming an important api in the react ecosystem and this article written by Dan Abramov is a good introduction to them including some of the rationale for why the api was created. For the use case in Gutenberg, the same reasons for hooks in general contribute to why they are being implemented here. Namely:

It’s hard to reuse stateful logic between components

As higher order components, withSelect and withDispatch do a great job at enhancing components to connect with the registry. However, they contribute to the “wrapper hell” commonly experienced in large react apps where stateful logic is shared between components.

Hooks provide a better primitive for interacting with stateful logic and useSelect and useDispatch in turn provide declarative interfaces for interacting with the store state without changing component hierarchy.

Complex components become hard to understand

While much of the complexity of interacting with store state is reduced in the usage of withSelect and withDispatch. The new hooks take this a few steps further:

  • The api is simplified.
  • The declarative behaviour is more straightforward to follow in the context of their implementation. Instead of having multiple withSelect or withDispatch calls, you can now embed useDispatch and useSelect within the components using them (or, preferably, create a custom hook implementing the multiple useSelect and useDispatch hooks and exposing only the props needed by the component).

Classes confuse both people and machines

While this applies more to hook usage in general, it does allow for not worrying as much about lifecycle methods and for implementing directly in functional components. Note, withSelect and withDispatch could also wrap functional components, but the exposure of hooks allows for integrating with the usage of other React hooks.


There will be documentation updated in @wordpress/data docs eventually, but for now, you can see the api and examples directly in the repository.

I’ve also written an overview/introduction to the hooks that gives some insight into usage.

#wordpress-data, #gutenberg, #javascript, #usedispatch, #useselect

JavaScript Chat Summary, June 4, 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: June 18 Meeting Planning

Slack Conversation

Neither @adamsilverstein nor @aduth will be able to host the meeting scheduled for June 18. Is there anyone willing to host that day, or should we plan to cancel the meeting for that week? This is the Tuesday before WordCamp Europe, so there may be lower-than-usual attendance.

Decision: There will be no JavaScript meeting on June 18.

Agenda: Dependabot Follow-up

Slack Conversation

Discussed in last week’s meeting, a bot has been submitting security update pull requests to the gutenberg-examples repository. It was discovered that this was a default behavior from GitHub’s acquisition and integration of Dependabot.

Proposal: If there will be a workflow which requires corresponding upstream patches for the WordPress core project, we should document it.

Since the pull requests are not being submitted to the Gutenberg repository, this workflow may not be necessary. The examples repository is standalone and is not mirrored upstream in any fashion.

Agenda: Broader Impact of Gutenberg Patterns

Slack Conversation

@nerrad raised a concern that patterns developed in Gutenberg may conflict or overlap with patterns in the broader wp-admin interface.

Example: The “Snackbar” iteration is relevant in the conversation about notifications in the administration screens.

Question: Are features which land in the plugin guaranteed to make their way to stable WordPress release? Answer: It’s not intended to be a given, iterations and feedback are to be solicited, and features can be guarded behind feature flags or dropped altogether. But ultimately, the current release workflow does result in most of these being put on a track toward a stable release.

Question: How do we avoid siloed decision-making?


  • These should be discussed beforehand in relevant teams with audiences outside Gutenberg specifically (#design was raised as having discussed this specific “Snackbar” iteration).
  • There should be some Trac conversation for the broader implications of the specific feature, and if/when this exists, regular updates should be provided to share iterations and solicit feedback.

Next Steps: Discuss the question of process for how decisions made in Gutenberg are handled in making their way to WordPress core. What are the problems, and who makes the decisions? Consider as a discussion point for a future devchat.

Open Floor

Slack Conversation

@nerrad shared that the useDispatch React hook is now available for use in Gutenberg master (pull request, documentation). This complements the useSelect React hook which had been merged last week (pull request, documentation).

@nerrad plans to publish a post about these new hooks on his own personal blog, and may cross-post or adapt the content into a post for Make/Core (this blog).

@gziolo shared that he has been making progress on improvements to the @wordpress/scripts package tools, including default paths for linting scripts, ensuring the build folder is ignored from validation (pull request), and supporting multiple entry points for build (pull request).

#core-js, #javascript

JavaScript chat summary, May 28th, 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: dependabot

@netweb started the topic by referring that dependabot was enabled in Gutenberg-examples and helphub repositories and the bot is currently creating PRs to update the package-lock.json dependencies.

A discussion about specificities about how npm versions work, what type of PR’s dependabot is creating, and why dependabot is enabled went on.

Agenda: Add type module commonjs to the corresponding packages

@gziolo referred that we have several packages which use CommonJS and questioned why not to mark them according to the new spec.

@gziolo shared the PR that applies the change referred above

@aduth asked if “type”: “commonjs” was not the default given that to be backward compatible having that default would probably be a need. @aduth added that he is looking forward to having consistent module import semantics across our packages.

@gziolo said he would do additional.

After meeting @gziolo commented on the referenced PR that he was able to confirm that commonjs is the default type, and proposed an alternative PR

Agenda: New things on the api

@nerrad referred that useSelectwas merged. And asked for thougths about useDispatch i.e useDispatch( storeName: string ): Object along with useDispatchWithMap( dispatchMap:function ): Object<function>.

@youknowriad asked:

what if it’s useStoreDispatch and useDispatch? I’m thinking that the map implementation is important for us, especially because we only want to call some selectors when the handler is called. So the question I have is about which implementation should be the default (called useDispatch)

@aduth also gave support to that approach because that way useSelect and useDispatch both accept a mapping function as an argument.

@epiqueras asked what the function gives that is not possible to do directly with the returned dispatch function?

@aduth answered that he thinks that the one thing is direct access to the registry, which is used in some places to help performance (only call a selector when the action is actually dispatched).

The alternative of useDispatch just returning dispatch right was suggested.

@nerrad referred:

I think with the move to hooks I actually prefer useDispatch to either return dispatch or actions for a specific store because typically useDispatch will be used in concert with useSelect in a component.
That provides flexibility for the component to take care of memoizing (via useCallback etc) any aggregate onClick events etc using the value from the select and the dispatches.

And referenced that useDispatch in redux does not receive a map.

For context, a link from the react-redux project was shared

People in the meeting arrived at a consensus that a good solution is just expose a single `useDispatch` without a mapping function that contains an optional parameter specifying the store name, and when called without argument just returns dispatch.

Other remarks

For people interested in GitHub Actions, @aduth explored a simple one to get the ball rolling:

Package publishes were improved with regards to managing two-factor auth passcodes:

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

JavaScript chat summary, May 21st, 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 next week’s agenda.

Maintaining Changelog

  • Updates to docs on maintaining packages change log.
  • Developers should not choose the version number for changes to packages, instead, add the changes to relevant subsection under “Master” heading.

Unstable APIs

  • Some discussion around listing and auditing various unstable APIs in use.
  • @nosolosw suggested automating the listing using JSDoc and was agreed upon.
  • These unsable API’s will be reviewed and removed on case by case basis.

Release Automation Tool

  • Current release process required manual intervention which was time consuming and prone to errors.
  • @youknowriad worked on the initial tool which helps in automating the process more details in PR

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

#core-js, #javascript