WordPress.org

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

Andrew Duthie 4:16 pm on June 4, 2019
Tags: core-js, design ( 21 ), javascript ( 74 )

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

Agenda: June 18 Meeting Planning

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

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

@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?

Considerations:

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

@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).

Jorge Costa 12:23 pm on May 29, 2019
Tags: core-js, javascript ( 74 ), meeting notes ( 38 )

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

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 https://github.com/WordPress/gutenberg/pull/15841.

@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 https://github.com/WordPress/gutenberg/pull/15879.

Agenda: New things on the wp.data 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 https://github.com/reduxjs/react-redux/blob/v7-hooks-alpha/src/hooks/useDispatch.js.

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: https://github.com/WordPress/gutenberg/pull/15826.

Package publishes were improved with regards to managing two-factor auth passcodes: https://github.com/WordPress/gutenberg/pull/15826.

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

Ajit Bohra 9:15 am on May 28, 2019
Tags: core-js, javascript ( 74 )

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

Omar Reiss 8:03 am on May 21, 2019
Tags: core-js, corejs ( 4 ), javascript ( 74 ), JS ( 3 )

JavaScript chat summary, May 14th, 2019

Below is a summary of the discussion from last week’s JavaScript chat (ag e nda, Slack Transcript)

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

Agenda: React Hooks for Data

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

Darren Ethier (nerrad) 2:47 pm on May 7, 2019
Tags: core-js, javascript ( 74 )

Javascript Chat Summary: May 7th, 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: React Hooks offering for wordpress/data

Context | Slack

There’s a bit of discussion surrounding implementing React Hooks in the WordPress use of javascript. Here’s some take-ways/actions from the discussion:

Experiment with a useSelect limited example to port an existing component (initial experiments owned by @nerrad)
Consider the broader context of higher-order components, and the impact of hooks:
- Which existing higher-order components can be ported? All of them?
- Do the interfaces change in porting to hooks?
- Would we ever find reason to create new higher-order components?

Please assist in working through this discussion. You can contribute thoughts in the related github issue.

Omar Reiss 11:39 am on March 28, 2019
Tags: core-js, corejs ( 4 ), javascript ( 74 ), meeting notes ( 38 )

JavaScript chat summary, March 26th, 2019

Below is a summary of the discussion from this week’s JavaScript chat (ag e nda, Slack Transcript)

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

Agenda: Building JavaScript

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

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

Agenda: Gutenberg Playground

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

Marcus Kazmierczak 1:04 pm on March 25, 2019
Tags: core-editor ( 123 ), core-js, javascript ( 74 )

Building JavaScript

The Gutenberg Handbook shows JavaScript examples in two syntaxes: ES5 and ESNext. These are version names for the JavaScript language standard definitions. You may also see elsewhere the names ES6, or ECMAScript 2015 mentioned. See the ECMAScript Wikipedia article for all the details.

ES5 code is compatible with WordPress’s minimum target for browser support. It can run straight in your browser and does not require an additional build step. In many cases, it will be perfectly fine to follow the same approach to start experimenting with your plugin or theme quickly. As soon as your codebase grows to hundreds of lines, it might be a good idea to take advantage of all the great JavaScript features included in ESNext syntax.

With the release of Gutenberg 5.3, the @wordpress/scripts package was updated to include webpack and Babel configurations. The update makes setting up an ESNext development environment much easier for building blocks and creates a standard method for developers to set up their plugin.

The documentation in the JavaScript tutorial and the ESNext examples in the gutenberg-examples repository are both updated to include the new process.

Here is a quick overview of how to set up an environment. First, you need to install @wordpress/scripts package:

npm install --save-dev @wordpress/scripts

You can then update the scripts section of your package.json to include:

"scripts": {
    "start": "wp-scripts start",
    "build": "wp-scripts build"
}

No webpack config (e.g., webpack.config.js) or Babel config (e.g., .babelrc) is needed.

The scripts expect the source file to be found at src/index.js and will output the build to build/index.js. So if you are migrating an existing plugin, you will need to move your source and enqueueing to these new locations.

With the setup in place, the standard workflow is:

Install dependencies: npm install
Start development builds: npm start
Develop. Test. Repeat.
Create production build: npm run build

In general, the package should be used with the set of recommended config files. While it is possible to override every single config file provided, if you have to, it means that your use case is more complicated than anticipated. We’d love hearing about it as we’d like to iterate on the current setup and offer more flexibility in the future. At the moment, our recommendation would be to use the underlying tools (webpack, Babel) directly.

See the JavaScript Build Setup documentation for a full explanation and walk through, and see the scripts package documentation for all the details.

Props to @gziolo and @nosolosw for their efforts.

#core-editor, #core-js, #javascript

Darren Ethier (nerrad) 3:04 pm on March 19, 2019
Tags: core-js, javascript ( 74 )

Javascript Chat Summary – March 19, 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: Reconciling WordPress and Gutenberg Script Handles

Context | Previous Effort | Slack

Some points there seemed to be consensus on:

As needed, existing scripts in WP core will be pulled into the GB repository, exposed as their own package, and then re-registered for use in core.
Old handles will still be present for back-compat, but redirect to new handles.

Initial effort regarding this will happen for:

shortcode package: https://core.trac.wordpress.org/ticket/44987
a11y package: https://core.trac.wordpress.org/ticket/45066

Agenda: How should uncaught errors be handled

Context | Slack

There was much discussion on not only the specific issue (see context) that triggered this agenda but also how this might be generalized. In conclusion, there was some consensus to explore something along the lines of [this solution](https://gist.github.com/aduth/f464f2d549a80716127a7e0d575b102f) in concert with implementing error boundaries in withSelect to see how they interact and work. So short-term focus will be on fixing the immediate issue with errors in subscriber listeners.

Further discussion effort on this will be done in the pull request @aduth will own this issue (in collaboration with others who help).

Agenda: Reusable Scripts

Context: here and here | Slack

This is work towards making the Javascript build setup for plugins much more simplified.

We reached the point where we exposed every tool Gutenberg uses adjusted for external plugins development
@gziolo

Related packages will be published soon.

Action Items:

update repository (once package is updated on npm) (@gziolo)
dev note about the package linking to the docs and repository (@gziolo)

Anton Timmermans 12:59 pm on March 13, 2019
Tags: core-js, javascript ( 74 )

JavaScript Chat Summary, March 12th, 2019

Below is a summary of 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.

Daylight savings time

@aduth proposed to not move the meeting time this instance, because for some people having the meeting an hour later means they can attend. If you have any feedback on this proposal, please leave a comment.

Default webpack configuration

Slack conversation

A default webpack configuration pull request has been merged to wp-scripts. So plugin authors can now do wp-scripts build and that will build their JavaScript into a bundle for the browser.

There was a brief discussion on whether or not the build command should accept a custom webpack configuration. For now this will stay possible. In the longer term the default configuration should be good enough for a lot of users and the Gutenberg webpack config should align with the default config as much as possible.

Pull request for typescript definitions

Slack conversation

The Gutenberg repository received a pull request with TypeScript definitions. This raised the broader question whether these pull requests should be accepted, because these definitions also need to be maintained.

In the chat the consensus was that it is only worth merging these kinds of PRs if the maintainability burden is very low. Given that is not the case it is probably better to not merge the given PR.

This will be decided on next week, please comment here with your ideas on this.

Removing grunt dependency from `grunt-patch-wordpress`

Slack conversation

@jorbin wants to make the grunt-patch-wordpress tool a general command-line utility that runs without a grunt dependency. Everyone agreed that this is a good idea. The new package will be located inside the monorepo like all other JavaScript packages.