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 wp.data 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!

Why?

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 wp.data 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.

How?

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?

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

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

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

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: 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.

#core-js, #javascript

JavaScript chat summary, April 30th, 2019

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

Webpack plugin to extract script dependencies

A status update on the state of automation for maintaining script dependencies. The pull request to replace the manually maintained packages-dependencies.php with a generated one is now merged. We discussed what the next steps would be for inclusion of this in core. For this the packages need to be released and a trac ticket created.

#javascript

JavaScript chat summary, April 23th, 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.

Webpack plugin to extract script dependencies

Another update was shared on a Webpack plugin discussed during the previous week’s meeting, which helps provide automation for the tedious and error-prone task of manually maintaining script dependencies. The pull request was merged this past week: PR#14869. It won’t be published to npm until WordPress 5.2 is released.

There’s a follow-up issue at PR#14837 which aims to replace the existing manually maintained packages-dependencies.php file in Gutenberg. There’s an open question there about how we handle “legacy” scripts which are still referenced on the window global, as these aren’t explicit but rather implicit dependencies. We discussed several possible solutions and decided to take the following steps:

  1. We know what these implicit dependencies are and which scripts depend on them, let’s merge those into the “extracted” set? There is already a follow-up PR#15124 opened (shortly after the meeting) by @jonsurrell.
  2. We were all in agreement that referencing the window globals is itself a problem we need to address. This is incompatible for use in an npm context and should be eliminated or substituted with an equivalent package. @aduth created an issue#15125 to keep track of it.

#javascript

JavaScript chat summary, April 16th, 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.

Closing the Loop: TypeScript

Slack Conversation | Previous Conversation

Question: What decision do we arrive at based on the previous discussion and comments?

Context: It had been an agenda topic for a meeting last month to consider whether to maintain and accept pull requests proposing to include TypeScript definitions in the project. As previously discussed, it was generally agreed upon to not maintain these in the project. Additional time was allotted to allow for asynchronous feedback. Since then, the topic had not been revisited.

Decision: TypeScript definitions will not be maintained in the Gutenberg repository.

Follow-up: In an effort to support those who may find benefit in these definitions, we should at least consider documenting third-party resources.

Action items:

  • Explain decision and close the related pull request. (Owner: @aduth)
  • Open a new documentation issue to outline the desired resources, and invite those from the affected pull request to provide feedback as to what specific information would most benefit interested developers and require the least ongoing maintenance. (Owner: @aduth)

Future of Block Registration

Slack Conversation | Previous Conversation

An update was shared on a proposed Webpack plugin discussed during the previous week’s meeting, which would help provide automation for the tedious and error-prone task of manually maintaining script dependencies. (Note: The pull request has since been merged)

Subsequent discussion was two-fold:

  • Could this plugin be used to help solve the unanswered question around asset management for the ongoing Blocks Registration RFC discussion? And if so, what would that look like?
    • There was some consideration about whether the manifest output by this tool, when used in combination with an explicit or implicit entry point to a block, could be sufficient to derive all necessary information to register and load a script and its dependencies.
  • Would this or its impact on the Blocks Registration RFC impact (for better or worse) an existing issue with load order of scripts and the challenge it poses to plugins who seek to extend blocks?
    • It was not considered to be directly related. However, there was some follow-up discussion about the use of filters generally, and whether the Blocks Registration RFC could have an impact in considering the registered block type to be aggregate of a series of patches (merging the block manifest, the client-side definition, and any third-party modifications).
    • Action Item: Continue discussion on the associated issue.

#javascript