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