JavaScript Chat Summary: December 3, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack Transcript).

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Follow-Up: Types Checking

(Slack conversation, previous meeting summary)

A new tracking issue was created for modules types effort, including some rough guidelines toward the bottom of the comment.

@aduth shared a small pull request to demonstrate how this task can look for simpler modules, as a point of reference for others who might be interested in contributed.

Last week, there was some discussion about necessary changes for the automated documentation tool (“docgen”). A summary of these findings was shared on the corresponding issue.

Discussion:

  • @gziolo mentions that the effectiveness this process will need to be validated by other volunteers.
  • @aduth suggests a simple approach to testing types in a file by adding // @ts-check as a line at the top of a file.
  • @gziolo suggests it could be helpful to create a screencast to demonstrate the effort, referencing a similar example shared by @mkaz.

Action items:

  • Consider recording a screencast to demonstrate the effort of converting a package to be typed. (Tentatively owned by @mkaz)

JSDoc Standards

(Slack conversation)

Using JSDoc for types validation will force us to write better, more accurate JSDoc, which may require some new or updated guidelines (see current guidelines).

A few specific examples are mentioned:

  • Deemphasis of Backbone guidelines
  • Updates with respect to modernized syntaxes, files structure
  • TypeScript-specific JSDoc syntax extensions

Discussion:

  • Since these observations are limited to Gutenberg-exclusive use of ES2015 modules for files structuring and TypeScript tooling, it may make more sense for these supplementary guidelines to exist in the Gutenberg documentation.
  • Taking cues from the coding guidelines, the handbook standard can serve as a base upon which Gutenberg-specific recommendations can extend. Common guidelines should live in the JSDoc handbook, proposed for migration as appropriate similar to that done previously for Gutenberg JavaScript standards.

Actions:

  • Propose standards documentation for JSDoc syntax relevant for clarifying uncertainties in the types-checking effort. (Owned by @aduth)

#core-js, #javascript

JavaScript Chat Summary: November 26, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agendaSlack Transcript). Thanks to @cbravobernal for compiling these notes.

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Open Floor: Types in Gutenberg

@aduth suggested to revisit the topic of improving types in Gutenberg. He mentions some work already done in URL module: https://github.com/WordPress/gutenberg/pull/17014

It was discussed to create a master issue with the progress of converting packages to use TypeScript validation based on JSDoc.

@gziolo fixed all ESLint warning related to the integration with the new plugin which combines JSDoc and ESLint, however this probably needs to be further investigated.

Action:

  • Create a tracking issue for module adoption of type checking
  • Push forward on effort to improve docgen ability to understand more of the TypeScript-specific syntax
  • Do some more conversions as demonstration

Open Floor: E2E Tests and Travis

Pushing a PR has been a bit of a chore recently with flakey tests, usually requiring a restart of a couple each time

For stability, it requires some diligence to investigate the underlying issues. Some improvements have been merged / proposed here:

@aduth have a few of these ideas in the Project Management Automation project board as well https://github.com/WordPress/gutenberg/projects/24

There was talk about documenting some of the common issues seen with E2E tests. Also to add a bot response with comments about the reasons of failing tests.

A CPU problem is mentioned: https://github.com/WordPress/gutenberg/pull/18770

Action: 

  • @noisysocks could look into some of this and write up findings/suggestions in an issue, not sure when though.

#core-js, #javascript

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

JavaScript chat summary, October 29nd, 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.

React prerelease channels

Slack Conversation

There was an announcement from the React team about official prerelease channels:

The long story short is they are promoting react@next prereleases and share some guidelines on how to test projects with the upcoming changes to their libraries. If you want to get involved and explore how the Gutenberg project could participate please comment on the corresponding issue.

Time of the meeting

Slack Conversation

Weekly meetings discuss JavaScript in the context of the WordPress ecosystem and we value the input from people working with JavaScript in WordPress. We wanted to survey people whether they would like to participate in the weekly chat if there was a different time?

As of today, we expect you’ll come to the meeting prepared to contribute your perspectives and help influence direction. You can also share in comments what would you expect from such meetings.

Testing components

Slack Conversation

There is an ongoing discussion about different approaches to testing UI components on GitHub. It isn’t a new topic. We have already considered removing enzyme in the past when some React APIs weren’t covered, but we gave up because of its wide usage.

We agreed that we can live with enzyme in old files following Code Refactoring guidelines, but we should plan to make it easier to contribute with tests when working on new features. @nerrad emphasized that it would be good to iron out what testing approach we want to recommend going forward. If anything the discussion in that issue highlights, we should include it in the Testing Overview documentation as the very first step.

@gziolo proposed we consider the E2E testing approach with the instance of Storybook as the testing environment given that it is a static site working like a single page application. @itsjonq shared that he’s done storybook E2E testing using Cypress in the past. It was something that could be automated by CI (Travis) and it worked great.

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

JavaScript chat summary, October 22nd, 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: Node LTS

Slack Conversation

Recently, Node 12 became the new LTS version for Node. A pull request to make WordPress scripts compatible with Node 12 was merged.

Agenda: Code style

Slack Conversation

A change to the JSDoc plugin triggered new ESLint warnings. These were fixed in a pull request: https://github.com/WordPress/gutenberg/pull/18025.

Another PR tries to bring WP Prettier into WP Scripts. WP Prettier is a Prettier fork that follows the WordPress code conventions that allows to easily reformat all of WordPress JavaScript but also enable other developers in the community who leverage WP scripts to do the same.

Agenda: Storybook

Slack Conversation

In September, Storybook was added to Gutenberg. There’s an issue open discussing next steps, which includes adding stories for all @wordpress/components and adding support for React Native components. @mkaz published a tutorial video on his blog on how to code a storybook story.

The following questions could be explored:

  • How can we enable plugin and theme developers to leverage storybook in their own workflows? It was suggested storybook could be added to WP scripts.
  • How can we integrate storybook into https://developer.wordpress.org/block-editor/? Storybook could be a replacement for the components reference.

A few concerns were raised with regard to using storybook on wordpress.org:

– How do we keep the WP dev site header?
– How do we avoid iframes (and include the header) to keep routing?
– How do we keep the READMEs (or some aspects of them) as there’s a lot of good info there?

It seems storybook allows for enough customization to be able to address these concerns. Some help from the meta team would be required.

Open floor: Card component

Slack Conversation

@itsjonq worked on a PR for a new Card component. There’s still some ongoing discussion about the introduction of css-in-js and Enzyme in that PR. Feedback appreciated!

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

Javascript Chat Summary – October 15, 2019

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack Transcript). Major props to @cbravobernal for wrangling it.

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Storybook

Storybook is a UI component explorer for frontend developers and designers.

@gziolo created a new label Storybook on GitHub to make it easier to discover related issues and PRs in Gutenberg.

In the meantime, contributors @mkaz and @itsjonq added the first stories with examples of UI components available at https://wordpress.github.io/gutenberg/design-system/components/?path=/story/introduction–page.

Adding @wordpress/components in Storybook is a straightforward way to start, as they are already some existing examples. Many people also voiced many advantages of using Storybook, emphasizing the easy way to explore which components Gutenberg provides.

The team also talked about benefits for having the master issue overview of the effort and a way to track progress.

@gziolo raised the issue of using Netlify for the playground and Storybook previews in PRs. Netlifly offers a special free plan for OSS projects but they require a link to be included on the project page which is something which might not work in the case of WordPress.

Action items:

  • create the master issue with the next steps for Storybook (@gziolo)
  • create individual issues with improvements to the Storybook setup (owner required)
  • discuss live preview for PRs and explore various options (owner required, with @nerrad ready to pick it up at a later time)

Monorepo – Mobile Gutenberg

The next topic was moving the Mobile Gutenberg codebase into the Gutenberg monorepo. @hypest opened the original issue nearly a year ago!

There is a draft PR which moves most of the code from wordpress-mobile/gutenberg-mobile respository to npm packages in WordPress/gutenberg repository.

@hypest requested help from someone with good web knowledge in order to check if that PR is going to cause any issues.

Action item: 

@gziolo will check this PR and help to merge once WordPress trunk is frozen during the process of the 5.3 release.

#javascript, #meeting-notes

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