Editor chat summary: Wednesday, 22 January 2020

This post summarizes the weekly editor chat meeting on Wednesday, 22 January 2020, 14:00 WET held in Slack.

Gutenberg 7.3

@gziolo announced that the Gutenberg 7.3 release was planned to happen later in the day and said, this release includes among others:

  • Multiple performance improvements.
  • A new block collections API. The API is useful when a developer wants to group the blocks in its section in the inserter.
  • Further improvements to the Navigation block.
  • New experimental blocks for the full site editing.

More details about this release are available on the release post.

Weekly Priorities

For this week, we keep the same priorities as last week:

  • Block Content Areas (Full site editing)
  • Block UI updates
  • Block Patterns
  • Navigation block improvements

Task Coordination

@karmatosed

Has been mostly focusing on navigation block feedback/iterations and global styles – will continue to do this into next week.

@retrofox

Has been working on adding the background color feature to the navigation block, it is already merged.

Now is improving the sub-menus design, and polishing the feature.

It is possible to track the progress in the project dashboard.

@isabel_brison

Worked on resizable editor PR https://github.com/WordPress/gutenberg/pull/19082.

All the tests are now updated, and it’s ready for further review. There’s a bit of discussion on how to isolate the editor-specific styles for manipulation in the core, any feedback appreciated at this point!

@youknowriad

Has been working on the icons package. Referred Icons are all over the place in Gutenberg right now, and thinks at least we should gather them in a single package. Said technology-wise, we still need to explore different options to how best ship them for authors, but a tree-shakeable npm package seems like the best initial path forward without BC concerns. @youknowriad will continue working on a solution to this problem.

@youknowriad is also working on an Extensibility API Proposal ( will share more very soon) and keeps doing heavy triage as time allows.

@andraganescu

Is working on an attempt to have responsive backgrounds in blocks which have image backgrounds, and doing various tidying up PRs for the navigation block.

@getdave, @marek, and @jeryj

Are working on the navigation block.

@jeryj is improving the UX.

@getdave and @marek are working on the ability to Create Pages from within the Block on the fly. Relevant issue and PR:

@nosolosw

@nosolosw is focusing back on the work on Gutenberg. Revived a lingering PR to fix a focus issue in the gallery block https://github.com/WordPress/gutenberg/pull/14930. The PR needs a technical review!

@jorgefilipecosta 

Since last week:

For the next week:

  • Help to have a “Global Styles” mechanism in the core.
  • Continue the work on Angle Picker and Gradient type picker for the custom gradients.
  • Focus on triage issues. Reviewing PR’s required for 5.4 beta 1.

@mapk 

@aduth

  • Helping around improvements and consistency among various link components
  • Hoping to try to push user-meta-based preferences persistence (sticky preferences) over the finish line. @aduth referred it would be a nice feature for WP 5.4.
  • Would like to visit some project management automation at some point.

@chopinbach

Is getting up to speed on Gutenberg development.

f you are also starting and are finding any challenge, please share it so that we can improve the experience for everyone.

@gziolo 

Open floor

Template lock active at the post type level, and templateLock={ false } in InnerBlocks causes an invalid block warning

@chrisvanpatten brought up issue https://github.com/WordPress/gutenberg/issues/11681 and asked if there are any options to move the issue forward as the issue is causing a frustrating experience. The ticket seems stalled without a clear path.

Currently, @chrisvanpatten  relies on dispatch('core/block-editor').setTemplateValidity(true); as workaround to the problem.

@youknowriad said the plan outlined in https://github.com/WordPress/gutenberg/issues/11681#issuecomment-549641097 seems a sensible one. But the ticket is stalled because implementing that solution is a big-time investment.

@chopinbach volunteered to help address this problem, and @chrisvanpatten volunteered to team up. Thank you both!

FormTokenField: Make it possible to add children

@scruffian asked for feedback on https://github.com/WordPress/gutenberg/pull/19676.

@youknowriad said that while the change is minimal, it would be good to expand on the use-cases. @youknowriad referred that adding random children may not be the best path forward, and asked if there is another abstraction possible, or if the button is something that can be built-in.

@scruffian said @youknowriad ideas are valid, but his thought was that it would be more useful as it was proposed in the PR. @scruffian  is open to achieving the result differently.

Server-side context API

@chopinbach asked for the latest updates on server-side context API @epiqueras is working on.

@epiqueras said the API is similar to React context and that he needs a PR review.

@youknowriad and @mcsf referred that ideally, a block consumes from a “contextname”, not a “blockname” and different blocks can use the same context name to expose their context.

@epiqueras linked to a comment providing some reasons where the approach may have problems.

The conversation will continue on https://github.com/WordPress/gutenberg/issues/19685. If you have any insights on this issue, please provide them as it may be valuable.

#chats, #core-editor, #editor-chat, #meeting, #meeting-notes, #summary

Javascript Chat Summary – January 7th, 2020

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: WordCamp Asia Contributor Booth

Slack | WCAsia Request

WordCamp Asia team is asking if folks from the #core-js team will be coming to the contributor day. From those at this week’s meeting, the following indicated they will be there:

Some topics that were suggested as things to work on during this day:

  • TypeScript
  • Storybook
  • Unit tests
  • Automating project management

The contributor table will be co-lead by @adamsilverstein, @aduth, @gziolo , @epiqueras (in some way, split between the Gutenberg and core-js tables)

Open Floor: Prettier Update

Slack | Github

Question: Is the goal to eventually run prettier on our existing codebase?

Answer: Yes, the goal is to run Prettier on the whole Gutenberg codebase and keep it formatted.

Open Floor: Move Some Build Tests to Github Actions

Slack | Github

@netweb recently added a Github Action to the Gutenberg Examples repository for doing a npm run build and jest tests. @gziolo thought it’d be good to do something similar in the Gutenberg repo to free up Travis jobs and get better feedback.

Open Floor: Use CSS-JS more widely?

Slack

@itsjonq asked:

I would love to know if using Emotion (or some CSS-in-JS method) is a strategy folks are comfortable with.

comfortable enough for some refactors to happen with the primitive components.

Initial big convo on CSS-in-JS was discussed in this github pull.

There was some discussion in the meeting about this with points ranging from strong reservations against using CSS-in-JS, to it being a good fit for @wordpress/components.

While it’s not clear there was a definite decision at the meeting, there seemed to be some consensus around this final point made by @youknowriad:

My personal opinion is that I’m fine with it being explored if it’s only for @wordpress/components for now without impact on external API

#javascript, #meeting-notes

Javascript Chat Summary: Tuesday, December 17, 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 the next chat agenda.

Next Javascript meeting is January 7th, 2020.

Because of a lot of people being AFK for their holidays we’ll skip the next two meetings.

Prettier

@aduth introduce the topic by saying:

There’s been quite a bit happening this past week, both in the comments of the revisions proposal post, and in the original pull request.

Post: https://make.wordpress.org/core/2019/12/09/proposed-javascript-coding-standards-revisions-for-prettier-compatibility/

Pull request: https://github.com/WordPress/gutenberg/pull/18048 

I think we’re in a position to make a decision on how to proceed here. From the feedback to the post, there are some general thoughts around improvements to the standard, but not any reluctance to Prettier specifically (quite the opposite, in fact!)

It would seem to me that most people are on board with this. Does anyone have any last-minute thoughts on this, or would it be fair to say we can move forward with adopting Prettier?

Based on the comments of the PR and the conversation in the chat, it seems we are in a position to merge this work.

@jsnajdr referred that the PR adds a format-js script to wp-scripts, and provides support for IDE integrations. Well-behaving Prettier editor integrations should pick up the config and the fork binary automatically.

@mkaz proposed a PR that documents these changes at https://github.com/WordPress/gutenberg/pull/19074.

The conversation went on @jsnajdr noted that the PR does not yet format the code, but we can easily format it with `wp-scripts format-js`.

@gziolo showed availability to collaborate/discuss with @jsnajdr how format-js will operate after the PR is merged.

@gziolo noted that having prettier code formatting will alow inline snapshots on the test cases https://jestjs.io/docs/en/snapshot-testing#inline-snapshots.

@aduth proposed the following action items:

  1. Merge @jsnajdr‘s pull request.
  2. Review, merge @mkaz developer tools documentation.
  3. Submit standards revisions changes.

After @jsnajdr‘s pull request is merged:

  1. Create a pull request to apply formatting to the entire codebase
  2. Explore options for automated formatting.

Participants agreed on the plan.

Block Scaffolding

@gziolo shared the following GIF showing block Scaffolding working:

Block Scaffolding Tool

@gziolo managed to implement ESNext template support with wp-scripts integration and is wondering if this scaffolding mechanism should be part of the Gutenberg repository.

Participants started discussing if this solution is part of the Gutenberg repository, what will happen to the current “official” scaffolding solution offered in WP-CLI. There are technical restrictions in making something equivalent to the solution @gziolo proposed on WP-CLI because WP-CLI should not depend on node.

@gziolo will continue iterating on the new scaffolding solution and, once tested, will import it into Gutenberg.

SVGR support in wp-scripts

@mkaz started the topic by saying:

I have a PR that adds SVG support to it which is a handy addition, but not sure if we want to add it without having the same support in core Gutenberg: https://github.com/WordPress/gutenberg/pull/18243 

For core blocks, we don’t inline SVG, we always code them, so this mechanism would not be used by core blocks, but it may be helpful for third party block developers.

@gziolo said Parcel 2 is heading in the direction of supporting CSS and SVG imports. @aduth said Parcel faces a similar challenge, and it may be a useful reference of how to address this problem.

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

Editor chat summary: Wednesday, 18 December 2019

This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, December 18, 2019, 14:00 UTC.

The agenda of the meeting is here.

Next core editor meeting is January 8th, 2020.

Because of a lot of people being AFK for their holidays we’ll skip the next two meetings and plan the next Gutenberg release (and #core-editor meeting) for January 8th, 2020.

Considering our consistent bi-weekly release schedule, there were 23 Gutenberg versions released in 2019.

Thanks to everyone who made this possible!

Task Coordination

Note: Anyone reading this summary outside of the meeting, please drop a comment in the post summary, if you can/want to help with something.

@andraganescu

  • I migrated the MediaReplaceFlow to the video, audio, file and media+text blocks and the PRs are waiting for a review. They’re all pretty small code wise: 19198, 19174, 19162, 19158.

@karmatosed

  • Triage continues and trying to ensure everything has a design review on PRs within short time.
  • Wrote v1 of triage team doc and it’s up on issue.
  • Spending sometime this week clearing down queues a bit and already finding I can close some, so nice to close!
  • Began working on navigation in wp-admin: working out boundaries for this.
  • Did some mobile web testing and logged some issues, continuing this.
  • Sentence case merged.
  • Quick fix for welcome guide.
  • Lots of design feedback and testing.

@noisysocks

  • No new development happening from me this week but I do have this open PR for deprecating wordpress/nux that I’d love some eyes on: 18981

@youknowriad

  • I’ve been working on a few PRs to improve API and consistency for the Button component
  • I’ve been working on a keyboard shortcuts package to ultimately allow editing shortcuts and registering third party ones
  • A few janitorial PRs

@aduth

  • Been doing some fixups: – Fix ArrowUp/parent block selection: 19135
  • Fix IE11 Welcome Modal: 19201
  • Would still like to land removal of “shortcuts” (needs review): 19045
  • Starting to explore user preferences persistence (more “sticky” than browser storage): 19177

Hoping to hit on a few things in next days:

  • Better data reuse for REST API _fields (opens up new optimization possibilities)
  • docgen improvements (edited) 

@mapk

  • Linking Media in Media + Text block is merged! 18139
  • Was hoping for some dev help on new Block Library categories: 11406
  • If the widgets screen is ready for testing, @jorgefilipecosta, I’d like to do some usability tests.
  • Usability testing the Nav block.

@ella

  • Been working on Raw handling, RichText, and slowly making progress with the toolbar in popover PR.

@epiqueras

  • Been working on edit-site and new entity APIs. Also template part editing flows.

@richtabor

  • I have one small tweak left for adding background color support to the columns block. Refactored it to use the ‘useColors’ hook. Next I’ll do the same for the Column block on a separate PR 17813

@isabel_brison

  • I’ve been working on making the editing canvas resizable, PR in progress here: 1908
  • Branching off from that, I’m starting to look at how we might optimise default block styles with CSS variables without breaking things completely in IE.

Open Floor

There was a lot of discussion on improved revision control. The main point raised by @Carike was that by using branched revisions, with minor and major designations, users will be able to use block based themes more easily. @epiqueras offered that branching or minor/major revisions are too complicated and a better improvement to revisions si to have them support block level changes.

The general agreement was that we need better revisions performance and UX.

The discussion continues in Track ticket #48953.

A second discussion happened about adding pagination to the latest posts block. There was a heated debate on whether pagination is a stand-alone block or simply a feature of blocks that need pagination. @karmatosed argued that pagination is not an option that an user might think as requireing inserting a block. @epiqueras argued pagination should be a block and be developed in such a way that if it is used standalone it would default to paginating the default post loop in the page, while other blocks might opt to use it by default (e.g. the latest posts block).

The issue is still up for debate, UX and technical solution in the GH issue #13584.

On a final note, happy holidays for those who do that and happy new year!

#meeting-notes, #core-editor, #editor, #gutenberg

Editor chat summary: Wednesday, 11 December 2019

This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, December 11, 2019, 14:00 UTC.

Gutenberg 7.1.0

  • Gutenberg 7.1.0 is released.
  • Massive progress on full site editing experience.
  • Some of the feature highlights:
    • New welcome UI in place of tips.
    • Table captions and UI to toggle between edit and select mode.
    • New fixed toolbar for mobile.
    • Improved multi-block selection experience.
  • This is a big release with 161 pull requests merged, for details checkout release post.

Weekly Priorities

  • Full site editing / block content areas
  • Block patterns API
  • Improvements to the Block UI  
  • Tightening up items

Task Coordination

Note: Anyone reading this summary outside of the meeting, please drop a comment in the post summary, if you can/want to help with something.

@youknowriad

@karmatosed

@mkaz

@aduth

@gziolo

  • Refactoring to the block toolbar, including some visual tweaks
  • Iterations to Build Tools: Integrate DependencyExtractionWebpackPlugin in the JS build https://core.trac.wordpress.org/ticket/48154
  • Reviews, including some learnings about TypeScript, JSDoc, etc.
  • Ported wp-cli scaffold block to npm init wordpress-block – this generates ES5 JS code, I plan to provide ESNext +JSX template as an option next week

Open Floor

#meeting-notes, #core-editor, #editor, #gutenberg

REST API Chat Summary: November 14

This post summarizes the weekly REST API chat meeting for November 7, 2019. (Slack transcriptAgenda). Weekly REST API component office hours are held every Thursday at 18:00 UTC in the #core-restapi room in the Make WordPress Slack.

Authentication

A new wp-api/authentication GitHub repository was created last week to facilitate the design & development of a REST API authentication solution for WordPress Core.

We continue to be in the information gathering stage. For all interested in contributing to this effort, we will be using part of our weekly REST API office hours each Thursday at 18:00 UTC (Thursday, November 14, 2019, 01:00 PM EST) as a weekly standup to coordinate work.

We also invite you to log issues describing use cases the authentication solution should support.

Registered Block Types REST API

#47620 aims to create REST API routes to discover the list of registered block types. It is based off the Gutenberg Block Type Registration RFC. @spacedmonkey worked on a patch and is in the process of soliciting feedback from the Gutenberg team, Mobile team, and other members of the REST API team.

A particular point of concern @spacedmonkey brought up was the difficulties about handling the asset fields ( editorScript, script, editorStyle and style ). The RFC defines the fields as either absolute URLs or relative paths to the source files. However the WP_Block_Type class defines those fields as asset handles.

Further the asset URL or handle is not sufficient to make the asset functional. The list of dependencies, inline scripts, translations, and localized data are all necessary for the script to work.

@timothyblynjacobs mentioned that the RFC discusses statically discovering that information from an associated .asset.json file located “next” to the script file. @aduth mentioned that section is slightly out of date since @wordpress/scripts now outputs a .php file instead of a JSON file.

The participants discussed whether it would be better to include this additional information inline in the Block Type response, or to develop a separate wp/v2/dependencies API.

@timothyblynjacobs suggested that including this information inline would be simpler. @spacedmonkey pointed out that then we’d be including full data from a separate resource within the block type response. Elsewhere in the REST API that would be handled by creating a separate API and linking to it.

Additionally, @timothyblynjacobs pointed out that just exposing the list of dependencies isn’t sufficient. The client needs access to the entire dependency graph to ensure each dependency’s dependencies are loaded, and that all scripts are loaded in the correct order.

This all points to a dedicated REST API endpoint being a better solution. The team then discussed the potential privacy and security ramifications about retrieving this information about any registered asset.

A developer may include sensitive data in a wp_localize_script or wp_add_inline_script after registering the script with wp_register_script. Currently, this data would only be exposed when the script is enqueued, which may be protected by a current_user_can or $hook-suffix check. If the REST API allowed returning information about an arbitrary asset handle, this data may be exposed.

Additionally, a developer may conditionally registers asset based on a plugin’s settings. By allowing a user to check if a handle is registered via the REST API, it may be possible to determine the setting configuration of a plugin. This may not be desirable for security or privacy related plugins.

@kadamwhite mentioned that historically the REST API has been pretty conservative about what data is exposed. If possible, he’d like to continue along that path. Or theoretically authentication could be required for some pieces of the API since the use case seems to mostly be for editorial interfaces which would require auth anyway. @spacedmonkey also suggested a capability check.

@spacedmonkey and @timothyblynjacobs proposed limiting the assets exposed to ones registered via WP_Block_Type and all WordPress Core assets. Additional assets could be exposed via a registration flag of some kind, like show_in_rest.

Both @aduth and @youknowriad mentioned that this functionality would not just be useful for blocks. As WordPress moves more and more to JS powered interfaces, the ability to lazy load assets will become increasingly important. The problem here could be generalized to “retrieve all the information necessary to properly load a handle”.

@youknowriad opened a ticket, #48654, to continue the discussion on Trac.

Agenda for November 21

The next REST API meeting is happening in #core-restapi at Thursday, November 21 at 18:00 UTC. Agenda:

  • REST API Authentication project weekly meeting
  • Menus API discussion
  • WP Dependencies API
  • Review open tickets which should be provisionally milestoned for 5.4
  • Open floor

#meeting-notes, #rest-api

Dev Chat Summary: November 13, 2019

@francina led this week’s dev chat – the last one of the 5.3 release cycle – see the agenda here.

For the full transcript, see the Slack archive here.

Your faithful reporter: @amykamala. Let’s get going!

Announcements

@francina opened Announcements with the release of WordPress 5.3, which went live on November 12, 2019!

She congratulated everyone, NOT just the folks active in the chat, on an amazing job. Several Core committers were especially pleased that 5.3 came in on schedule (🎉) with the biggest group of contributors ever.

Here are a few statistics:

  • 12 weeks of development
  • A release squad with nine focus leads, covering every relevant component that got an update
  • 645 contributors
  • 658 bugfixes
  • A new default theme, Twenty Twenty
  • Lots of fun and new friends made
  • And much, much more!

Before release the squad counted at least 153 user-experience enhancements.

Highlighted Posts

The annual WordPress survey is open! Your feedback is not just appreciated – it’s vital to the future of WordPress. So please fill it out and share it everywhere you can think of.

Tanking the floor for a moment, @chanthaboune told the group this survey is new – not the same as last year – and is broader. Whether you’re a contributor, designers, developers, users or hosts, please participate!

Again, please share the survey with anyone who touches WordPress in any way.

5.3 Housekeeping

Big thanks to everyone who has helped with testing so far! If that includes you, please keep testing and report any issues, concerns or enhancement ideas in a comment on Trac.

That’s how WordPress gets better and you get to shepherd your best ideas through the process.

Need a refresher on how it works? Here’s an outline of the post-release process.

@francina wrapped the discussion with a note that in the next few weeks the release leads will open a call for retrospective. Want to share some honest, constructive feedback? That’ll be your chance!

5.3 Housekeeping Calls from component maintainers

@francina opened the floor for component maintainers to bring up topics for discussion. These are the components.

@marybaum said “I love that we have a #core-css channel. Does that mean Core CSS is a component?”

@peterwilsoncc replied, “it’s closer to a focus than a component. Tickets can still be assigned to the affected component, eg Admin, Themes, etc. “

@sergey asked “If we have a `javascript` focus, should we add one for CSS as well? 

After a few more comments from folks, @francina reminded all 30,000-plus potential attendees that we don’t make final decisions in devchat.

She asked the folks talking about CSS to follow this process:

  • Make a proposal on the Core blog
  • Discuss
  • Come to a conclusion
  • Act

Here are the reports from other component maintainers:

@williampatton: “Themes component is looking good. Prepping for next release.” 

@peterwilsoncc: “From the security team, now we have a Travis CI account that allows for private repos, we have the security tests running regularly. It should make it easier to find out if they’re passing during the release process.” and went on to ask @sergey if it was possible to add it to Trac.

@garret-eclipse: “In the privacy component @rogierlankhorst has started work on a consent api.

Open Floor

@mensmaximus asked whether “we ever change the user management screen to a tabbed interface. What is the current state and what do core devs think?”

@williampatton started with a general reply: “There are lots of thoughts on redesign for user management, but lots of ideas mean lots of decisions [making it] hard to reach agreement.”

A lively discussion followed. Hopefully the WordPress world will see some new ideas for an even more usable Admin experience!

(Ed. note: The UX discussion and the conversation below, about jQuery, happened at the same time, and you’ll see the comments jump from one to the other. Still, imo, both are worth your time and effort to decipher!)

@enrico.sorcinelli has “noticed that Juery’s `$` is no longer globally defined in admin.” That’s made some of their client sites cause issues with users’ code.

@clorith answered, “The jQuery `$` being globally available was a bug.” That bug got fixed in one of the JS updates in 5.3.

“Although it’s not ideal, reports of issues are fewer than expected, and the code errors would be within the plugin code,” @clorith continued, adding, “I tend to lean towards leaving it being the right thing.” 

Here’s the ticket they’re talking about and the full discussion, including some observations on the future of jQuery.

@clorith noticed two items leading the pack of recurring issues, 24 hours in:

  • The update to add_submenu_page gives doing-it-wrong errors. We knew this, but devs weren’t prepared for users to have debugging enabled. 
  • The change to spread operators had plugins breaking, because things like custom walkers had dependencies on the previous operators.

See the full discussion starting at the link above. (Ed. note: this highlighted test is the same link.)

@pbiron asked if anyone had reported problems with the new big-images or rotate-on-upload features. 

@clorith and others noted very few issues.


#5-3, #devchat, #meeting-notes

REST API Chat Summary: November 7

This post summarizes the weekly REST API chat meeting for November 7, 2019. (Slack transcript, Agenda). Please note that this meeting did not change time for daylight savings, and Weekly REST API component office hours continue to be held every Thursday at 18:00 UTC in the #core-restapi room in the Make WordPress Slack. 🙂

Authentication

The first half of the meeting discussed the newly-created wp-api/authentication GitHub repository, a follow-up to discussions at WCUS contributor day around rebooting work towards a canonical, core Authentication solution to permit the Mobile team to use the REST API instead of XMLRPC.

Our target for a merge proposal some time next year is to have an use the OAuth 2 handshake flow with dynamic client registration, which issues revocable, long-lived JWT tokens. The repo has no content so far, but we will start work by focusing on UX and the desired user-facing and technical flow rather than diving immediately into code.

@spacedmonkey, @derekherman, and others intend to drive this project over the coming months. If you who is reading this or any colleagues of yours are interested in contributing to this effort, we will be using part of our weekly REST API office hours each Thursday at 18:00 UTC (Thursday at 18:00 UTC) as a weekly standup to coordinate work.

Priorities & Goals

Priorities for Next Release

Key tickets highlighted for consideration as part of the next release cycle include, but are not limited to,

  • Improve performance in route matching #48530
  • Support registered default meta values #43941
  • Permit schema filtering #47779

If you have a ticket to highlight or propose for the next bugfix or major release, please leave it as a comment below or raise it in #core-restapi. Thank you once more, as well, to everybody who helped drive our API improvements in 5.3!

Documentation

We are behind schedule in updating the REST API handbook to cover the recent changes in WordPress 5.3. @timothyblynjacobs and @kadamwhite will be working to roll these updates out over the coming week. Handbook content is managed at github.com/wp-api/docs.

Open Floor

@timothyblynjacobs raised #44568 and #44886. Because WordPress operations are non-atomic, these race condition issues are not limited to the REST API and were determined to be out-of-scope, so #44886 was closed as wontfix.

Several bugs were raised and have been provisionally milestoned for 5.4, with the option to backport as needed once addressed.

To increase contributor awareness of REST API tickets, we discussed holding periodic component scrub meetings in the main #core channel.

Agenda for November 14

The next REST API meeting is happening shortly in #core-restapi at Thursday, November 14, 18:00 UTC. Agenda:

  • REST API Authentication project weekly meeting
  • Review open tickets which should be provisionally milestoned for 5.4
  • Open floor

#meeting-notes, #rest-api

Javascript Chat Summary – November 12, 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.

Switching to Prettier

Slack | Github Issue

Some discussion ensued on what is needed to merge this pull.

  • Post on make.wordpress.org regarding any code standard changes affected by this pull (and to inform about the change). This will need further feedback from core lead devs, core committers and contributors.
  • There are some rule removals from the es-lint plugin package, some discussion ensued about how to handle that and are those changes necessary. At a minimum, there seems to be some agreement that the ESLint rules should match the standards.

Tasks:

  • Check how many of the existing eslint rules could stay unmodified and what can be tweaked to work with Prettier and which need to be disabled. Should align with whatever standards are for the project (including any necessary modifications to those standards)
  • We should also seek a way so that the eslint plugin can continue to be used without prettier so folks can have the benefit of styling standard checks the same way as of today.
  • Once the above is done, write a post on make.wordpress.org/core outlining the changes and inviting feedback.

__experimentalCreateInterpolateElement

Slack | Github

This is a new function that makes it possible to interpolate elements within a translated string and have those rendered as react elements. Currently, doing something like the following can’t be done in react.

const MyLinkComponent = ( { href } ) => {
    return wp.i18n.__( 'This is a <a href={ href }>link</a>' );
};

In order to have <a> render, you’d need to split up the string, which in turn breaks context for translations. The solution is __experimentalCreateInterpolateElement:

const MyLinkComponent = ( { href } ) => {
    return __experimentalCreateInterpolateElement(
        wp.i18n.__( 'This is a <a>link</a>' ),
        { a: <a href={ href } /> }
    );
};

If you have any feedback or concerns with the proposed api please give feedback in the pull.

In the meeting:

  • generally seems to be approval around the api
  • concerns over whether the parsing should be cached.
  • wondering whether there’d be value in introducing a useInterpolation hook (that could also take care of some of the caching)
  • adding some sort of performance testing (although since it’s not used anywhere, there’s nothing currently in the project that can help with this).

Upcoming React Features

Slack

In this portion of the meeting there was mostly just some resource and link sharing around upcoming react features:

  • https://reactjs.org/docs/concurrent-mode-adoption.html
  • https://reactjs.org/blog/2019/11/06/building-great-user-experiences-with-concurrent-mode-and-suspense.html
  • https://www.youtube.com/playlist?list=PLPxbbTqCLbGHPxZpw4xj_Wwg8-fdNxJRh (React Conf 2019 playlist)

#javascript, #meeting-notes

Javascript Chat Summary: Tuesday, November 5, 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.

Editor-specific .gitignore entries in Gutenberg

  • Context: https://github.com/WordPress/gutenberg/pull/18257#discussion_r342255694
    • Proposing to add a gitignore entry for VSCode’s “.vscode” local folder
  • Historically we’ve avoided editor-specific entries in the project’s gitignore to avoid opening pandora’s box (proliferation of ignore entries), but is this too rigid a guideline causing friction in new contributor onboarding?
  • Question: Should we allow more of these entries, and if so, which?

@gziolo said that he does not have a strong opinion on this item, but WordPress as a project is strict about it.

@mkaz also does not feels strong either way but said he would probably merge the PR because vscode its perhaps the largest and most popular editor.

@chancethedev shared his perspective as an instructor:

I often include vscode settings in my repos to make things easier for students when running workshops, so ignoring it globally won’t work for me. That said, I can just remember to remove it before I commit so it’s not a HUGE deal, I can just imagine folks slipping up often enough to where it’ll end up in commits from time-to-time and we’ll just have the conversation again.

@aduth and @adamsilverstein asked if the fact that WordPress os strict is written down somewhere?

@gziolo shared the following comment from https://core.trac.wordpress.org/ticket/34345:

IDE-specific .gitignore rules should not be present in a project. They should be managed in the user’s ~/.gitignore_global.

@gziolo added that it does not look like it is a written rule, as he was not able to find it in the docs. So, we can go both ways; we should document it to make it easy for contributors to update patches.

@nerrad said :

I lean towards adding the rule and just evaluating on a case-by-case basis.

It seems to be more dev friendly and avoids unnecessary noise in reviews.

@mkaz asked if there is any downside to adding the rule and @aduth answered:

I don’t think there’s a downside in-and-of-itself, more the slippery slope of how we make these decisions in the future without a well-defined approach.

@adamsilverstein suggested as action item working on some language for HOW we decide.

@mkaz and @gziolo suggested we add 3-5 top popular IDEs. @gziolo said we could also link to docs how to add an IDE to ~/.gitignore_global.

@aduth suggested, and @adamsilverstein supported that we can base it on “X% or greater” of some well-defined data, e.g., https://insights.stackoverflow.com/survey/2019#technology-_-most-popular-development-environments.

@chancethedev said he is joining the docs team specifically for Gutenberg docs, so he is happy to bring this up in the docs meeting today as well.

If you have any thoughts on this, please share them.

Bundling and loaders – extend core to allow SVG components

As part of the open floor, @mkaz introduced the topic by saying: 

For the open floor, I’m interested in the topic above regarding bundling and loaders – trying to extend core to allow SVG components.

Parcel sounds like an interesting option but looks like v2 is not out yet, so would need to wait

@aduth asked clarification on the background of this task and what is trying to be achieved by importing an SVG.

@mkas linked to the ticket https://github.com/WordPress/gutenberg/issues/14628 and said:

Right now the Social Links duplicates the SVG in CSS and PHP to work – we want to figure out some way to get it to a single .svg file

@aduth asked if it’d be feasible to manually shove the SVG into JSX. And asked if not an option to use something like <img src="icon.svg">.

@mkaz answered that the problem for the publishing view is KSES, and linking to images, one loses the ability to color them.

@aduth shared the main questions he thinks we should answer are “Should we do it, and if so, how?” and shared some thoughts :

  • I am conscious of the size inflation, though I think we need to be solving this problem anyways. Could be a way to prompt us to investigate better handling of “large” blocks (opening path for more complex blocks too, like reintroducing Code+SyntaxHighlighting).
  • I guess there is some issue with our build that the Webpack loader might not work? The Babel transform seems less ideal, but also workable.

@gziolo shared the following analysis of what creat react app did:

CRA experiments with Babel macros, but the blocker at the moment is cache invalidation. They had a very solid proposal to inline many types of files, including SVG with Babel macros https://github.com/facebook/create-react-app/issues/3722#issuecomment-458124126.

Macros struggle with the cache invalidation for the dependent files. See the comment in create-react-app https://github.com/facebook/create-react-app/commit/11737bc78676868e76ce5d0c04ddbb5c758d3908#diff-b1524f1e1ccabdb327a12f23b432b20bR13.

Related Babel issue which might resolve this issue in the future: https://github.com/babel/babel/issues/8497.

@mkaz said Parcel 2 sounds like a potential option for the future. Then, asked if we want to add SVGR support to wp-scripts without it in core Gutenberg, relevant PR https://github.com/WordPress/gutenberg/pull/18243. @gziolo answered that we use a custom config in Gutenberg, so it should be fine.

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