Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.
@netweb started the topic by referring that dependabot was enabled in Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/-examples and helphub repositories and the bot is currently creating PRs to update the
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( storeName: string ): Object along with
useDispatchWithMap( dispatchMap:function ): Object<function>.
what if it’s
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
@aduth also gave support to that approach because that way u
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.
I think with the move to hooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. 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 A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing..
For people interested in GitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ 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.