JavaScript Chat Summary – June 26th

Below is a summary of the discussion from this week’s JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. chat (agenda, Slack transcript).

Participants: @omarreiss, @aduth, @herregroen, @nerrad, @abdullahramzan, @azaozz, @adamsilverstein, @youknowriad

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

Sunsetting the Packages Repository

It’s been proposed that all modules published through NPM be moved from the WordPress/packages repository to the WordPress/gutenberg repository.

Motivations:

• The packages setup is already duplicated in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/.
• Some Gutenberg packages can’t be moved at the moment to the packages repository to avoid splitting the work between two different repositories.
• Having a unique location to publish packages.
• One less repository for WP.
• Preparation for eventual merge to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
• Implies the potential of Gutenberg to be bigger than WordPress.
• Helps process for making in-place updates to packages for Gutenberg use-cases without going through the tedious flow of Packages PR -> NPM publish -> Gutenberg PR.

Decision: It’s been agreed that packages are to be merged into the Gutenberg repository. @omarreiss has been volunteered to create a pull request which would preserve the commit history for packages in the transition.

An Alternative to wp.apiRequest

Problem: The current argument and return value signature of wp.apiRequest binds us to jQuery.

Proposal: Create a new, separate wp.fetch module as a replacement, based on the standard window.fetch browser API.

Decision: It’s been agreed to move forward with the new wp.fetch script and deprecate wp.apiRequest. Separately, an observation has been noted that all future work should avoid hard dependencies on third-party scripts.

Deprecation Strategy

(Continued from last week’s discussion)

Problem: How can we introduce breaking changes necessary for user benefit without sacrificing a commitment to backwards compatibility?

Options:

• Create separate scripts and allow the originals to remain forever.
  • Downside: User impact in code size from loading many variations of the same sorts of scripts.
• Communicate a strategy to move away from the deprecated feature, then remove the feature after a predefined amount of time.
  • Important that this is a well-defined timeframe, and communication is centralized.

Prior Art: Gutenberg’s Deprecated Features

Action Items:

• Explore options for how communication and migrations can be assured, for both developers (visibility to the removals) and users (compatibility between plugins and future versions of WordPress).
  • Collaborate on a proposal document
• Create a JavaScript-specific variant of the Deprecated Functions page.
• Propose for discussion in a Core Dev meeting.

Data Module Improvements

There are two proposals by @youknowriad for major improvements to the data module:

• Introduce registry to allow for instantiating multiple of the same store
  • Needed in Gutenberg for proposed refactoring of shared blocks as an embedded editor.
  • Challenges:
    • Integrating with Redux DevTools
    • Interoperability with globals holding state (wp.data, wp.hooks, wp.plugins)
• Support asynchronous data flows using synchronous generators
  • Pros and cons outlined within the pull request comment
  • Main challenge is whether generators are to be easy to understand, though are arguably simpler to read than the current effects.js side-effects behaviors in Gutenberg (much indirection).

Build Process

Feedback is requested on the following tickets:

• #44371 – Make sure all JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. globals are explicitly assigned to the window.
• #43731 – Use Webpack + NPM scripts to build all the things

Progress has been made by @omarreiss on a new grunt build:dev command which symlinks the php files on systems that allow symlinking to make the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher only workflow much smoother.

Inline Documentation

Reminder that the JSDocs Initiative could use your help to ensure that all JavaScript files in core are properly documented. This is a great way for new contributors to get involved and learn about WordPress’ JavaScript along the way.

Update: Documentation for six files have been committed since WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe 2018.