Javascript Chat Summary – October 8, 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.

Open Floor

There was no agenda items this week so the meeting was spent with open floor.

Storybook Chat

Spent a bit of time chatting about efforts to get storybook working (slack)

Related pulls:

Also:

WordPress 5.3 Notes

  • will include an updated version of Backbone that introduces some back-compat breaking changes (related trac ticket). If you use backbone in your plugin/theme, worth checking to make sure everything still works. A dev note will be published soon including details.
#javascript, #meeting-notes

Javascript Chat Summary: October 1, 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.

WordPress 5.3 progress

@gziolo announced that WordPress 5.3 release beta 2 is out. @gziolo asked if participants know if there any tasks left related to JavaScript core.

@jorgefilipecosta referred https://core.trac.wordpress.org/ticket/47527 as a small JS patch that should fix a bug in the media library. The patch should be ready and needs a review. A review there would be much appreciated.

@gziolo continued by saying it would be important to merge https://core.trac.wordpress.org/ticket/48154, which would simplify updating npm packages in WP core. But there is still this pending issue to address:

Where to put generated asset files to be consumed by PHP? At the moment they are generated in the folder, which in usual is exposed as client-side assets.

In case you have any ideas, please provide your insights on the ticket.

CSS support in wordpress/scripts

@gziolo introduced the subject by saying that it is something that we discussed some time ago in core-js chat. It’s tracked under https://github.com/WordPress/gutenberg/issues/14801, and it was primarily explored by @fabiankaegy in https://github.com/WordPress/gutenberg/pull/14847

Participants started discussing the challenge of CSS support in wordpress/scripts.

@gziolo shared some context:

In Gutenberg we don’t import CSS in JS files. Instead, we have a separate build step that converts the SCSS files into CSS files which are published to npm. There is some additional step performed by webpack, but I guess it’s mostly about ensuring the LTR version is produced as well.

@nerrad said:

I do think we should have @wordpress/scripts as a utility that builds CSS as well. But getting to something that addresses the various needs of those consuming it is the difficulty here.

@nerrad concluded that we need to decide the defaults for the CSS build system with ways to override them via CLI args.

@gziolo continued and said that ideally, we should be able to reuse as much as possible of what Gutenberg uses internally. This is the only way to ensure plugin/theme developers get all updates out of the box.

@gziolo questioned why developers default to importing CSS in JS file. @jsnajdr provided an answer to the question and then explained how the webpack runtime loads the assets. @gziolo found the mechanism interesting and said we should definitely explore alternatives in how we manage assets in WordPress core to better align with what JavaScript ecosystem offers these days. 

@gziolo continued the conversation and said that the mobile team is exploring how to build cross-platform UI components.

This is the PR https://github.com/WordPress/gutenberg/pull/17614 which explores styled-system and styled-components.

@pinarol said we want to reach a point where we can build blocks with a cross-platform components library which enables us to implement a block once and run it on both web/mobile.

This requires the mobile team to find a way to have a common styling system with the web, and since CSS is not supported by React Native we started to investigate styled-system and styled-components. @pinarol concluded by saying that this is a problem we want to solve as soon as possible.

@gziolo said that the approach used for multiplatform comments is directly related to work of making wordpress/scripts support CSS.

Storybook

@gziolo announced that we are considering adding Storybook to help with the development of UI components.

It is possible to leave feedback on the PR’s that propose this addition https://github.com/WordPress/gutenberg/pull/17475 and https://github.com/WordPress/gutenberg/pull/17173. They are alternative versions for a similar goal.

@ajitbohra also implemented a similar solution outside of the Gutenberg repository and said he would love to consolidate efforts.

Custom element interoperability

@flixos90 proposed a PR that includes CustomElement interoperability for block types

If you care about the support for web components in Gutenberg, give the PR https://github.com/WordPress/gutenberg/pull/17649 a spin and help to land it.

In case, you have any insights or suggestions please share them on the PR.

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

JavaScript chat summary, September 24th, 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 this week’s agenda.

New JavaScript APIs and support for previous versions of WordPress

Discussion: @adamsilverstein suggested that we add a developer guide section to explain how to write plugins that use newly introduced JavaScript APIs to work with older versions of WordPress. The biggest challenge is how to approach APIs which are exposed by new modules available under the wp global namespace.

We encourage plugin developers to share their strategies in the comments so we could work on the official recommendations on how to tackle this issue.

We also agreed that a good start would be to enforce using the @since pragma in JSDoc comments for all public APIs present in JavaScript code. This is something that is taken for granted in PHP codebase.

Action items:

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

JavaScript chat summary, Sept. 10th, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript). Thanks to @cbravobernal for putting these notes together.

Agenda: Upgrading jQuery when user on the front end.

@adamsilverstein comment the idea of upgrading jQuery on the front end, due to the crashes that appear if you try to update the wp-admin part. There was discussion about removing jQuery from all WP, but is a hard task to do and we have still to be compatible with old browsers like IE11.

Action:

Anything new should either not use jQuery or at the very least work with the current version correctly.

Keep the discussion going in the ticket and hopefully we can arrive at a way forward.

Out of agenda: jQuery dependency on admin bar

@williampatton raised this Issue regarding the jQuery dependency of the admin bar.

The main discussion is what to do, use a temporary patch (for 2020 theme we are considering just enqueueing jQuery) or try to completely remove the jQuery dependency of that admin bar.

Seems that a “hoverintent” is the main problem of removing jQuery there, also other keyboard actions should be checked before removing it.

Action: 

Keep tracking the issue

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

JavaScript chat summary, August 27th, 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: Cross-platform packages

Slack Conversation

In the near future we want to publish a mobile components library to allow cross-platform development of blocks, how can we document mobile/web specific props? The proposal currently only touches README files which are manually crafted. So far we assumed that this code is only used in WordPress. How could we make packages that are interoperable with both React DOM and React Native?

The mobile team is trying to make the API’s / Prop interfaces for mobile and webcomponents as similar as possible. But it will be hard to make them entirely the same. So we need to make sure we find a way to manage the documentation for these things better. Jorge Bernal will work on a proposal based on https://github.com/WordPress/gutenberg/pull/17145.

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

JavaScript Chat Summary: Aug. 20th, 2019

Below is a of the discussion from this week’s JavaScript chat (agenda, Slack Transcript). Thanks to @c4rl0sbr4v0 for taking these notes.

Our agenda was empty this week so all discussion arose from the open floor.

Introducing a new icon package

@nadir says that they will clean the PR of files auto-generated files and also that they were looking at a way to treeshake without the need to import individual icons manually.

There has been a discussion about including all icons in a wp.icons variable

  • Advantages:
    • Plugin developers that don’t use any build system have the ability to access our icons in their code.
  • Disadvantages:
    • We can’t load +1000 icon in a single script.

Possible solutions:

  • Select, download and manually include your icons in a web/cli tool like lodash or Material design.

This is a tough issue exploring the requirement for devs to include or not a build system and if this is overkill just to include a few icons.

Action:

Keep the discussion going in the ticket and hopefully we can arrive at a way forward.

Source maps in firefox

@pierlo asks for help with this issue:

Unable to load source maps from webpack in Firefox

@swissspidy asked if this is also a Gutenberg issue, referring a solution here

Action: 

No actions debated in Slack channel.

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

Javascript Chat Summary: August 13, 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: Shared Core Dependencies

Slack

The Google Doc Agenda has much of the content of what was discussed, but as a summary:

Package/Bundle size for assets is a significant concern for frontend use as WordPress continues to expand javascript as a first class citizen in its ecosystem. Some examples where this surfaces are:

  • using wp.element on the frontend. It has a dependency on lodash which adds weight to page load.
  • implementing various components or blocks on the frontend (wp.components itself has significant size).

Some potential ways to resolve/improve this for not only frontend but also admin are:

Load externals via CDN.

Externals such as react, react-dom, lodash etc could still be registered but the source would be from CDN. The advantage here is with WP’s wide reach, it’s much more likely that client browsers will have cached the asset for visitors to WP sites. Currently that’s less likely because of every site hosting it’s own assets by default.

Action: @adamsilverstein is going to raise this in the hosting meeting to get feedback from there.

Size of packages.

Here, the focus is on how big are we willing to allow various bundles to get? For instance wp.components is 553kB minified.

  • should we start thinking about setting some comfortable limits on how big we allow bundles to get? (tools like bundlesize could help with that)
  • what ways can bundles be further reduced in size (example of @wordpress/server-side-render being extracted into it’s own package) – audit packages and see what other extractions/groupings can be done?
  • WP core supports script-aliases (enqueuing wp-components could actually enqueue X different files behind the scenes, all populating the wp global).
  • Reduce external dependencies: Example is lodash dependency removal from @wordpress/element. Much of the functionality of lodash can be implemented via native js.

Action:

  • It’d be good if those interested in javascript in WordPress start thinking through some of what’s been discussed in this item and contribute some proposals on how to improve things.
  • On the last item, removing lodash dependency from WordPress packages has been proposed. It’d be nice to get a decision on moving forward there. Please contribute your thoughts to the issue!

Agenda: Lazy Loading of Images and Frames

Slack | Trac | lazysizes library | Native lazy-loading for the web article

The discussion here centered around whether lazy loading of images is something that should be implemented in WordPress core and some initial ideas on what would be involved in doing that. Some highlights of the discussion (though no concrete decision was made):

  • opt-in for now
  • possibly implemented via add-theme-support
  • include for wp-admin as well (eg. Media Library)

Action:

  • continue to contribute to the trac ticket. Possibly explore landing something for wp-admin first.

Open Floor

  • @joyously asked about the status/possibility of updating jQuery (see trac ticket (slack convo). Nothing concrete from the discussion. Current blockers are the difficulty in resolving issues with the update and conflicts/failures with the customizer and media. Also reluctance exists to invest effort in something that may become obsolete due to changes in framework used (moving to more react heavy admin). Joy did note that the biggest problem existing right now are the flags raised by security scanners detecting the version number (author note: vulnerabilities in jQuery bundled with core are patched, but security scanners still detect it as a vulnerable version).

#javascript, #meeting-notes

Javascript Chat Summary: August 6, 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.

Publishing npm packages

@gziolo announced that we published to npm new versions of all WordPress packages.

@gziolo added that we didn’t publish to npm in the last two months, although we could do it given that Gutenberg release happens every other week.

@gziolo asked for thoughts on how we can improve the process overall, and maybe automate it.

People noticed that the current process involves lots of manual work.

Some options were discussed, @gziolo noted that he does not think we can publish to npm from CI since we require all accounts to use 2FA.

@nerrad suggested we can do an iteration on the automation scripts @youknowriad build andding something like `commander deploy:trunk`.

@jorgefilipecosta noted that an automation tool will face a problem when merging Gutenberg PHP changes to core.

@youknowriad agreed and added that the PHP could never be automated. Both repositories have different PHP setups/requirements (one is a plugin on top of the other). But noted PHP is the small part of the work, and a helper tool could compare versions and say, we have these PHP changes, don’t forget to backport them.

In continuation of the PHP code updates conversation, @omarreiss added that:

Normally I would solve a problem like this by treating the Gutenberg PHP as a dependency of WordPress core. We could install that and keep that up to date by using composer. There is a ticket open for managing external PHP dependencies with the composer, but it’s not moving very fast, see https://core.trac.wordpress.org/ticket/47256. If that were the case, we could register an alternative initializer/autoloader when Gutenberg is active, and we would be done. The only problem is that the PHP in Gutenberg isn’t well isolated. To really solve this problem, the PHP in Gutenberg needs to start behaving like a more clean dependency, and we should centralize its initialization. This would require some refactoring. I wouldn’t mind exploring this approach, but I’d like some blessings on the direction from people like @pento and @jorbin first.

@youknowriad noted that @omarreiss suggestion means re-architecture WordPress to be built using PHP modules (same as we do with JS). @omarreiss agreed and said that was the reason why he does not want to explore further without some openness to the direction.

Help build an automation tool

@gziolo asked if we have someone willing to explore how we can automate as much as possible to make the process on WordPress core side less time-consuming and error-prone?

@dsifford said that he does not want to get distracted from the other work he is currently doing (jsdoc improvements), but we can consider him a fallback in case no one takes up this task.

If this task is something that interests you, and you want to expand knowledge about scripting and automation, please tell us about your interest in the comments.

Gutenberg Examples repository

@gziolo opened the topic by saying that we still maintain a repository with Gutenberg examples (https://github.com/WordPress/gutenberg-examples), and asked:

What’s the process like for such repositories with merging changes? I have PR opened, and I have no idea what to do next: https://github.com/WordPress/gutenberg-examples/pull/83

@netweb answered:

What I typically see is another Gutenberg core dev will to a drive-by review, approve and merge. So, nothing official.

The conversation continued and aborded specific subjects related to the PR @gziolo referred.

@gziolo concluded that although this repository isn’t as popular as others, we should still go through review/approve process as it’s useful.

Other subjects

@dsifford asked for reviews on PR https://github.com/WordPress/gutenberg/pull/16869 – “Add eslint-plugin-jsdoc for better JSDoc linting“.

People talked a little bit about that PR and chat participants provided some feedback.

Meanwhile, after the chat, the PR got a review, was approved and merged.

#core-js, #javascript, #meeting, #summary

Javascript Chat Summary: July 30, 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.

Housekeeping

Slack Conversation

@gziolo substitutes @aduth as the chat’s co-host in the next 3 months while he enjoys well deserved time off. It was a good opportunity to refresh the group of Note Takers. Kudos to @cbravobernal for volunteering to help with summary posts like this one. For those who still would like to get involved let us know. Here is the document which explains in-depth what does it entail.

Type Definitions

Slack Conversation

First, there is some exciting news to share for those who use TypeScript in their workflows. The last of the DefinitelyTyped submissions for package type definitions has been merged. Great work @dsifford on the related PR.

We also discussed possible next steps in terms of improving the auto-generated documentation. There was a general agreement that we should seek ways to improve the current approach with JSDoc comments before we jump into deep integration with TypeScript.

Action items

  • Replace the existing JSDoc ESLint rules with eslint-plugin-jsdoc (GitHub issue).
  • Improve existing JSDoc comments as we enable TypeScript checking gradually for all packages. This task should be coordinated with the tracking issue on GitHub.

#core-js, #javascript

Javascript Chat Summary: July 9, 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: Documentation Standards – @yield

Current Standards | Github Example | JsDocs| Slack

Some discussion around documentation standards for the @yield JSDoc tag:

Should the @yield JSDoc tag (used for generator functions) be considered as part of a grouping with @return?

There seemed to be consensus to consider @yield usage to be a separate grouping (newline between other “groups”, only aligned to itself).

Action: @aduth will update the documentations page to address the standards.

Open Floor

  • @nerrad requested eyes on https://github.com/WordPress/gutenberg/pull/16374 (slack)

#core-js, #javascript