Editor chat summary: 15 January 2020

This post summarizes the latest weekly Editor meeting, held in the #core-editor Slack channel, on Wednesday, January 15, 2020, 14:00 UTC. These meetings coordinate collaboration in the development evolution of the Gutenberg project. Facilitator: @pbrocks Notetaker: @itsjusteileen.

Weekly Priorities

We’re working on a few post-related blocks to use for FSE templates (starting very basic) and improvements to the block UI is being iterated on here PR 19344. The navigation  block is also very important as we get closer to WordPress 5.4:

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

Task Coordination

@andraganescu:

  • Adding niceties to the media replace control and tidy up issues for the navigation block

@youknowriad:

  • I’ve been working a little bit on the LinkControl component (code cleaning essentially) and trying to use it in more than just the Navigation block.
  • I’ve helped a little bit on what we call G2 (new Block UI)
  • I’m also doing a push on triage as the issues and PRs are getting out of control 
  • Reviewing some FSE PRs

@scruffian:

  • The site title block doesn’t work for non-admin users; to address this we need to make some REST API changes — please review #48885 (REST API: Add a route to read and update separate site settings) – WordPress Trac

@gziolo:

  • Polishing npm init wordpress-block script, and plans to open PR against Gutenberg next week (demo in the thread)
  • Continued explorations on how Patterns API could be integrated in the inserte 

@karmatosed:

  • Navigation: reviews, iterations.
  • Global styles: mocks and flows, trying to sync work there.
  • A continuous undercurrent of triage.

@retrofox:

  • Background Color for the <Navigation /> block. Pretty close to get a first solid approach.

@jeryj:

  • Various small improvements to the navigation block and color picker component.

@mapk:

  • Moving some links around to minimize the repetition of “Tools” areas in the interface: 
  • PR 19499
  • PR 19400
  • Looking at Template and Template Part UX flows.
  • Posts block design ideas.

@getdave working on: 

  • Focusing on how to improve LinkControl both within Navigation Block and also when in use in wider Editor. Lots of movement here by others also to make this component more useful.

@michaelarestad working on:

  • List of Epics for Full Site Editing
  • Flows
  • Iterating on mocks to reflect recent changes

@mcsf working on:

  • Exploring how we can take block patterns, as @gziolo is working on, to simplify / converge how we implement Embeds and hopefully Social Icons

@isabel_brison working on:

  • Brought Resizable Editor work to a reviewable state: PR 19082 (tests are still failing, but feedback on implementation appreciated)

Open Floor

Changelog Entry Standard

@nadir is looking for a way for PR others and maintainers to write a standardized PR changelog entry that can be aggregated by a script that generates the changelog. Initial idea discussion in Slack

@youknowriad provided steps he used for Gutenberg release:

  • Go through the list of all PRs merged for that release and milestone them properly
  • Copy the title of these PRs and add a link to the PR as a changelog entry
  • Choose the right section (bug, enhancement, new feature, new API, experiment, documentation or various) for each entry.
  • Reword the title properly so it reads similarly for all entries (same format). A lot of PR names are not worded properly
  • Gather related items together using sublists (a11y, several enhancements to the same block….)
  • Gather PR links in the same Changelog entry if a PR fixes a regression introduced by another PR in the same release.

From that list @nadir created a script (which we should commit) that does the second step (and part of the third one) automatically. This is already a huge time saver but would be good to introduce more normalization/flows to PRs in order to avoid the need to do the rewording.

Benefits include: 

  • help make each release easier with less manual work involved even if some PRs still need to be documented by hand.
  • reinforces that all PRs need a label so none are left behind.
  • encourages organization around how labels are applied, titles are used, etc, which benefits more than just changelogs, but also searchability of the issue tracker more generally.

@nadir pointed out the script also supports skipping PRs that have a special label, in Woo it’s skip-changelog, which could be applied here if a PR is not meant to be in the changelog.

@youknowriad indicated one step needed to execute could be to match all categories (bug, enhancement, new feature, new API, experiment, documentation or various) with a “[Type] something” label.

@getdave noted updates to the PR merging documentation would need to occur about adding the correct labels before merging, and @mkaz pointed out it would be a good idea to simplify the current list of types, or create a new specific set. @youknowriad volunteered post meeting to filter that list of types so Type could be equivalent to Changelog entry category.

Terminology Change — Align to Position

@getdave@matias raised a point about potentially renaming Block “Align” controls to “Position” and repurpose “Align” to mean something more akin to “Justify”.

To be clear, the new terminology could be:

  1. Position – how the container is displayed (wide, full-width, floated, etc).
  2. Align – for the distributions of elements within the container (left, center, space-between).

This would be a fairly significant change across the Editor and feedback is requested. Discussion is currently happening within PR 193686 for the Social Block but should become its own issue.

@matias noted alignments were used for position (floats, wide, and full) because of legacy reasons (WP had used alignleft, right and center for a long time). We distinguished between text alignment and block alignment, but it always left wide and full-width in weird places. Now we have newer blocks that need internal alignment controls (buttons, menus, social icons) and the inclination was to call this tool “justification”, but it’s also not the most intuitive. It seems the clearest and most meaningful names would be:

  • Position (floats, center, wide, full-width).
  • Text Alignment (left, center, right, justified).
  • Alignment (for flex-based left, center, space-between, etc).

These would need to be handled with care, though, to transition the components, APIs, classes, etc, without breaking anything.

Image Sizing

@paaljoachim noticed that the image in the Media & Text block becomes very huge on mobile. There should be a way to decide the size of the image used. This issue mentions image resizing PR 14483. Everywhere an image is used there should also be a way to resize it.

Dev Chat Agenda for January 15, 2020 (5.4 Week 1)

Here is the agenda for the weekly meeting happening later today: Wednesday, January 15, 2020, at 09:00 PM UTC.

Announcements

We are kicking off WordPress 5.4 this week!

Components Check-in

Open Floor


If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

This meeting is held in the #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#5-4, #agenda, #core, #devchat

WP Notify Meeting Recap – January 13 2020

This is a recap of the WP Notify meeting held on Monday, January 13, 2020, 14:00 UTC. You can read the meeting discussion here.

We’re resuming our work on the WP Notify project with better focus on actionable ways to address the challenge of notifications in WordPress.

We started by answering more pointed questions as to what the solution must address, and whether a temporary alternative should be entertained at all.

Temporary Solution

@psykro suggested to post a separate trac ticket, to improve the current admin_notices implementation, with sample code from @apedog

The benefit to this is that, as a team, we get something into core that improves users lives and we gain some real world experience of how the process could be improved by the final solution.

The negative is that it would mean this code is likely to be eventually replaced by our final, better solution. This very discussion, is the reason we want to present this concept to the community, for feedback on whether to a) expand admin_notices, or b) affirm the need for an entirely new replacement solution altogether, and what are the critical elements of that new approach

@schlessera is of the opinion, and rightly so, that any work done to improve the current admin_notices functionality is not worth the time. We should rather work on a solid, scalable and manageable solution for notification channels.

Permanent Solution (From The Onset)

A few of the very direct questions we must address for the replacement solution as suggested by @folleto are

  • What are we replacing? (if anything)
  • What kind of backward compatibility do we need?
  • What’s the minimal API and UI we need to build for a v1?

As we answer these questions, we’re keeping in mind the end-user experience together with the API required. For example, a notifications menu will need a completely new way of handling notifications in WordPress API through use of the database and rendering those messages.

As @schlessera pointed out “The initial UI should satisfy the 80% need of letting Core/plugins/themes communicate platform state changes within the admin dashboard in a scalable way where the user/user group keeps control.”

Meeting time

During the course of the meeting it became somewhat clear that the time of the meeting might be causing some problems for folks in different time zones. Conversation in the meeting became much more active after the first hour. Therefore we would like to know if the current meeting time is suitable, or if we should consider an alternative?

Next-Steps

Please comment with your thoughts below. You can also add comments your comments in the WP Notifications Project Google Doc under Section 1. “Objectives”

Next Slack Meeting

📅 Monday, January 20 @ 14:00 UTC

#feature-plugins, #feature-notifications, #summary

Editor Chat Agenda: 15th January, 2020

Note taker: @itsjusteileen

This is the agenda for the weekly editor chat scheduled for 2020-01-15 14:00 UTC.

This meeting is held in the #core-editor channel in the Making WordPress Slack.

  • Weekly Priorities
  • Task Coordination
  • Open Floor

If you have anything to share for the Task Coordination section, please leave it as a comment on this post.

If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#agenda#core-editor#editor-chat

WordPress 5.4 Planning Roundup

According to the tentative release schedule for 2020-2021, we are due to start 5.4 this week.

These are the milestones, based on the previous cycle:

  • Kickoff: 14 15 January 2020
  • Beta 1: 11 February 2020 (4 weeks from kickoff)
  • Release Candidate 1: 03 March 2020 (3 weeks from beta 1)
  • General Release: 31 March 2020 (3 weeks from release candidate 1)

Proposed WordPress 5.4 Scope

The main goal for 2020 is full site editing via Gutenberg.

For 5.4 these are the tasks:

As with every release, all component maintainers and teams are invited to prioritize their bug-fixes and enhancements for 5.4. Some suggestions that came from a few maintainers included:

  • Build/Test Tools
    • Add support for the newer versions of PHPUnit
  • Comments
    • The component was dormant for a while so during this cycle the new maintainers will do gardening and bug fixing
  • Design
    • The Design Team has a long list of issues they want to work through and they are polishing it for publication.
  • Privacy
    • UI Improvements
  • Site Health
  • REST API
    • Performance improvement
    • Work on endpoints needed by Gutenberg (Menu API and Settings API)
  • Users
    • Changes to sites with a large number of users
    • Tweaks to REST API endpoints
  • Media

In addition, all components and teams are invited to continue polishing current interactions and making the UIs more user-friendly.

I also collected all the proposals from the open call for tickets: I will submit them to the relevant component maintainers so they can evaluate if there are enough resources to address them during this release cycle and update the status.

Please bear in mind, if a ticket is still waiting for review, has no patch, or no owner, it is unlikely that it will land in 5.4. This shouldn’t stop you from continuing to work on it, gather feedback and ultimately polish it enough to have it in a future release.

Proposed WordPress 5.4 Leads

This section is still pending some answers. I will fill it in as I get Yeses and Noes from people. 

The roles needed for the release are:

  • Design Coordinator
  • Editor Tech
  • Editor Design
  • Core Tech
  • Docs Coordinator
  • Docs Writer

@matt will continue his role as release lead.

As suggested by @desrosj in a comment, it makes sense to have some roles not change for every release because it takes a while to learn and pass on the information. So David Baumwald and I will stay on for at least a couple more releases, as Triage PM and Release Coordinator respectively. The goal is for us to learn enough so we can then mentor a new group of release and focus leads.

Let’s do this!

#5-4 #planning

WP Notify weekly meeting notification for Monday 13 January 2020

The WP Notify feature project continues in 2020, with our first meeting of the year to be held on Monday, January 13, 2020, 14:00 UTC. We will take this opportunity to review the current status of the project, determine where we are at, where we need to go, and how we need to get there.

As the project has been on hiatus since late 2019, there is no fixed agenda, but I’ve listed a few items below we will be discussing.

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

This meeting is held in the #feature-notifications channel , to join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #feature-notifications

Dev Chat summary: January 8, 2020

The chat was facilitated by @francina on this agenda.

Full meeting transcript on Slack

Upcoming Release – WordPress 5.4

@francina reminded the main feature of 2020 will be full site editing. All component maintainers received a ping before Christmas to put together a scope for WordPress 5.4. An open call for tickets was also published on Make/Core. While @francina noted there were mostly bugfixes and not so many new features, @audrasjb raised ticket #48850 from the comments of this post. This ticket is related to automatic updates for plugins (with manual opt-in), which is one of the 9 projects for 2019-2020.

@azaozz noted that the media component team plan to continue with image post-processing. It looks like it will need couple of small UI changes/enhancements.

@audrasjb added the accessibility team will probably focus on bugfixes on both Gutenberg and Core for 5.4, and target the next major (5.5) for bigger new features.

Highlighted posts

@francina noted that a lot of volunteers signed up to the release model working group. @francina will write a recap post on Make/Core.

Worth noting @azaozz published a 5.3 release cycle post-mortem.

Components check-in

Comments: @imath is working on #35214. Feedback welcome.

Core privacy: @xkon said the privacy team won’t have any specific focuses for 5.4, only bugfixing & enhancements on existing parts. Some of them need backward compatibility review, especially #44038 and #44176. Both tickets have a patch and are ready for further iterations if needed.

Media: @azaozz is experimenting with #44427. Seems a very worthwhile enhancement for 5.4.

Open floor

In the agenda comments, @justinahinon pointed out some editing needed in the roadmap, and highlighted reactions of the community concerning handling of big media on WP 5.3. @azaozz noted most comments are about “missing” the original image in some way. The initial plan was to have a link to it in the user interface. It should be added in 5.4. Another enhancement for the UI would/may be to show when an image is missing some of the sub-sizes and have a way to create them. There are plugins that handle this, but may be time to have it in core. There are couple of pre-existing edge-cases that need fixing too. Most notably increase of the file size for indexed PNGs when resized to smaller dimensions.

@timothyblynjacobs shared #47192 as a possible 5.4 feature. It’d bring a pretty often requested feature to Recovery Mode. It would need design and copy input as well as a security review from people familiar with the intricacies of the Users/Capabilities API.

#5-4, #devchat, #release-process, #summaries

Media Meeting Recap – January 9, 2020

Here’s a summary of the #core-media chat from January 9, 2020. Weekly media meetings happen on Thursdays at 14:00 UTC; see the full transcript here, in the Make WordPress Slack.

Attendees: @joemcgill, @karmatosed, @antpb

Upcoming Meeting Schedule

Happy 2020! Because of the holidays, the group postponed chats until Thursday, January 9.

This morning, the group also discussed moving the regular time, so more people can join the chat – particularly people working on critical tickets in the 5.4 release cycle.

Here are three options. Vote for your favorite in the comments:

  • Move the current Thursday 14:00 UTC time to 15:00 UTC
  • Move the date to Tuesday at 21:00 UTC (this option works well for the three who came to today’s meeting.)
  • Multiple meetings, to account for both sides of the world. This option would likely require a push of the currently scheduled meeting to 15:00 or 16:00 UTC as well as an agreed time and date for the second meeting. @joemcgill suggested that multiple meetings not be forced to cover the same agenda items. Some items will overlap where it makes sense, but, for example, if one meeting has cleared the ticket queue, it would be pointless for the next meeting to consist largely of a triage.

New Media ticket triage

#48194 – Unregistered image sizes used for IMG tag “srcset”

As @joemcgill pointed out: “The problem here seems to be that someone has deleted image files that are still referenced in the database in attachment metadata. Regenerating image sizes ( wp media regenerate ) would fix this problem, but should we only use registered sizes in `srcset` attributes if there are other sizes available?”

#48321 – Hotswapping featured image with gallery images

It seems the ask is for (after creating gallery) the option to click on one of the gallery items and set as featured image of the associated post. It was agreed by attendees that this may not be best fit in the gallery block UI and perhaps would be better fit as an option within the media modal when creating galleries, images, etc.

The group changed the ticket to ask for reporter feedback.

@karmatosed made another point. The “Uploaded to this post” filter, in the Set Featured Image modal, does give the reporter part of what they’re asking for.

#48325 – Additional filter in media-template.php. Let developers hide attachment page link.

@joemcgill pointed us to the code that creates the attachment link: https://github.com/WordPress/WordPress/blob/master/wp-includes/media-template.php#L511 and said, “At minimum, I think that template should check that data.link is actually a URL before displaying [it]. [Developers] could filter the data that is used by this template.”

WordPress 5.4 Media Focuses

While it didn’t come up in the meeting, notes are a great place for all of us to develop ideas for Media focuses in 5.4.

If you have any media-related focuses you’d like to work on in the 5.4 cycle, and that you’re ready to work on, please leave a comment.

That helps the Media maintainers gather and prioritize the work. Plus, it would be great if you’d come to next week’s chat so we can all discuss your idea!

#core, #core-accessibility, #core-media, #media, #summary

What’s new in Gutenberg? (8 January)

The first Gutenberg release of 2020 includes not less than 180 PRs 😍crafted by more than 56 contributors. These change include some of the most asked for features from the community.

It includes a new Buttons block to align more than one button in a row. Several block plugins had this block available already and now it made its way into Gutenberg Core.

Accessibility-wise, a new tabbing behaviour has been introduced for Edit mode (mode you’re in when you’re editing blocks). Tabbing forward out of the block will bring you to the end of the content (the sidebar) and tabbing backward will bring you to the block toolbar and then the header. This makes it easier to navigate the editor and brings it closer other editors that let tabbing focus the next element outside the editor, rather than the next element inside the editor. Of course you can still navigate to other blocks with the arrow keys and by escaping the Navigation mode (press Enter to return to Edit mode, arrow keys or tab to navigate to other blocks).

From a developper perspective, this release also includes a big refactoring to the Button component: It now supports an icon prop and the design have been tweaked for more consistency across the different variations.

A new package @wordpress/keyboard-shortcuts has been added. Ultimately, this package will allow users to edit their keyboard shortcut combinations and third-party developers to register their own keyboard shortcuts.

7.2

New Features

  • Add a new Buttons block. 17352
  • Support adding links to Media & Text block image. 18139
  • Navigation block: Support changing the font size. 19127
  • Gallery block: Add images size selector. 18581

Enhancements

  • Improve the block inserter search algorithm. 19122
  • Improve the block placeholders design and responsiveness. 18745
  • Navigation mode: Auto-enable when tabbing to the block list with an existing block selection. 19238 19298
  • Use tabs for gradient and color. 19133
  • Add “download” keyword to the File block. 18995
  • Add “poem” keyword to the Verse block. 19355
  • Convert to blocks:
    • preserve text alignment. 19097
    • Skip shortcode if not on its own line. 19059
  • Writing flow: Improve tabbing for Edit mode. 19235
  • Use Popover for the block toolbar. 18779
  • Improve the block multi-selection styles. 19094 19121
  • Support reduced-motion for Social Links transitions. 18750
  • Use the default cursor for Select Tool 19157
  • Round position attributes on cover focal point save. 19183
  • Remove block inserter shortcuts. 19045
  • Navigation block:
    • Clarify the placeholder label. 19105
    • Removes the reusable block option from the items. 19250
    • Sub-items white background adjustment. 18976
  • Adjustments to the welcome guide. 19195
  • Audio block: Don’t render an empty audio tag. 18850
  • Make validation of block html tags and attributes case insensitive 19207
  • Block examples: concatenate strings and add translators notes. 19048
  • Show the trash button as a link. 19131
  • Removed the bottom-margin for the RadioControl component. 19340
  • Copy:
    • Capitalize “Manager” in Block Manager. 19375
    • Expand on sentence case usage. 18758 19377
    • Update the copy of the Experiments page 18233
    • Removes title case from alignments for text and image. 18757
    • Unify not capitalizing the heading for each of the attributes. 19374
    • Updates description of the navigation block. 19098

Performance

  • Remove the BlockAsyncRenderProvider and render parents asynchronously 19343

Bugs

  • A11y:
    • Make text alignment items radio menu items. 19233
    • Add group role to the block wrapper element. 19213
    • Prevent tabbing to the block drag handle. 19211
    • Add a label attribute to the Social Icons block. 18651
    • Improve Welcome guide and modal component. 19261 19290
  • Pasting:
    • Content that results in a new block shouldn’t be treated as inline content. 19084
    • Preserve inline images. 19064
    • Remove trailing br elements. 19035
    • Remove windows paste markers. 19040
    • Strip HTML formatting space for inline text. 19043
    • Apply active formats when pasting inline. 14815
  • Rich Text:
    • Fix applying a format across 2 other formats. 19053
    • Fix using composed characters on Safari. 19171
  • Fix block navigation using the up arrow key. 19135
  • Fix Welcome Guide modal display for Internet Explorer. 19201
  • Fix Gallery block crashing on the contributor role. 19060
  • Only show available image sizes for Image and Gallery blocks. 19301
  • Remove the circle mask style from the Image block, and add a “rounded” style instead. 19028
  • Fix the Jest Preset Default package: Update preset file extension for inclusion in NPM deployments. 19306
  • Fix the Base Styles package: Import colors into variables. 19159
  • Limit the Next Page (Page Break) block to root level only. 18260
  • Navigation mode: fix reverse tabbing to the post title. 19305
  • Reposition Popovers on click. 19268
  • Fix RangeControl initialPosition prop to accept 0 as a value. 18611 19202
  • CustomSelectControl: Use items width instead of 100%. 19150
  • Verse block: fix white space. 19173
  • Add missing i18n to the Latest Posts block settings strings 19032
  • Fix ColorPicker alpha value normalization. 18991
  • Fix Post title encoding. 19187
  • Fix dates alignments in the picker. 19294
  • Media Replace Flow: Don’t show the URL option unless there is a handler. 19063
  • Popover: don’t render fallback anchor if anchorRef is defined. 19308
  • Fix cursor position when splitting blocks with IME keyboard. 19055
  • URLInput: Avoid showing the suggestions loader when disabled. 18979
  • Translate block example strings. 18162
  • Writing flow: simplify & fix tabbing out of block. 19312

New APIs

  • Button component:
    • Support the icon prop and use a consistent button height. 19193 19366 19123 19058
    • Deprecate IconButton and replace its usage with Button. 19299 19241
    • Support isPressed prop in Button and SVG components. 17748
  • New the wordpress/keyboard-shortcuts package:
  • New React hook: useInstanceId. 19091
  • Support running arbitrary commands on the wordpress/env containers and use it for linting and server registered fixtures. 18986
  • Font Size Picker: Add default size 18273

Experiments

  • Full Site Editing:
    • Add package with barebones site editor screen. 19054
    • Add Multi-Entity Saving flow. 18029 19155
  • Widgets screen & customizer:
    • Fix Customiser block editor crash. 19023
    • Fix Drag & Drop not working on the widgets screen. 19029
  • Allow parent Block to consume child Block’s toolbar. 18440
  • Allow disabling the Block UI. 18173
  • Block Directory:
    • Update the regular expression that determines whether the plugin is using an img URL or an icon slug. 19316
    • Use the block’s title for alt text on block directory plugin items. 19263

Documentation

  • Add types documention:
    • wordpress/a11y 19096
    • wordpress/blob 19092
    • wordpress/dom-ready 19089
    • wordpress/is-shallow-equal 19090
    • wordpress/priority-queue 18997
    • wordpress/i18n 19099
  • Document the CustomSelectControl component. 19026
  • Document the WritingFlow component. 19314
  • Link to the User Support Documentation. 19361
  • Add more documentation for wordpress/env. 19194
  • Add nested block / InnerBlocks tutorial. 17559
  • Add Developer Tools setup in Getting Started. 19074
  • Use ESNext as default code example format. 17873
  • Add standalone npm package release docs 19381
  • Typos and tweaks: 19280 19236 19376 19146 19022 19005 18423 19347

Various

  • Block Editor: Remove legacy “editor-” class name compatibility. 19050
  • Block Editor: Test ContrastChecker notices by string comparison. 19169
  • Fix useColors crashes on storybook. 19046
  • Data: Remove unused forceRender argument 19206
  • Define useSelect dependencies properly. 19044
  • Deprecate wordpress/nux package. 18981
  • E2E Test Utils: Remove empty, unused KeyboardMode file. 19166
  • Popover: remove buffer options 19283
  • Refactor the MediaReplaceFlow component to use Dropdown. 19126
  • Remove unused is-hovered class from the block wrapper. 19390
  • RichText:
    • Rewrite withFilters with hooks. 19117
    • split out boundary style calculation. 19319
  • WritingFlow: rewrite with hooks. 19393
  • Project management: Add prepublish packages command for npm releases. 19214
  • Remove unused blocks-font-size classname. 19208
  • Add a pre-commit hook to check whether API docs are updated. 18820
  • Add mechanism to set a width on withViewportMatch. 17085
  • Add minimum and maximum values to the Gallery columns attribute. 16314
  • Include demo block templates in build ZIP. 19072
  • Fix CSS Coding Standards issue. 19272
  • Resolve WordPress package type imports. 18927
  • Add e2e tests:
    • Splitting and merging text. 19049
    • InnerBlocks renderAppender. 14996
    • Navigation block. 19189
    • Validate embed rendering before proceeding to next 19042
  • Add unit tests to the useViewportMatch and useMediaQuery React hooks. 19019

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~ 36000 words, ~ 1000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience but is adequate for spotting variations in performance.

Version Loading Time KeyPress event (typing)
Gutenberg 7.2.0 6.233s 66.615ms
Gutenberg 7.1.0 5.669s 71.415ms
WordPress 5.3 6.481ms 69.865ms

#core-editor, #editor, #gutenberg

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