JavaScript Chat Summary for May 23rd

Below is a summary of the discussion from yesterday’s JavaScript chat (agenda):

Introducing a JS module pattern to WordPress

@omarreiss helped lead the discussion and kick-started the conversation by opening a detailed and thoughtful ticket in trac (#40834) which introduces modules, their goals and how we could go about using them in core. The discussion was around considerations specific to WordPress and a need for modularity was mentioned – @westonruter called out this need for the Customizer,  see #30277. Ideas for code that could be extracted into modules included quickedit, core date utilities and wp.media.view.FocusManager.

The decision was made to move in the direction of using Webpack (and ES6 imports) as our bundler of choice, and to work first on switching out browserfy in our current build chain.

Choosing a future JavaScript framework

Discussion started on choosing a new framework for use in core. The main frameworks discussed so far were React and Vue. Attendees shared their hope, goals and criteria for choosing a new framework and mentioned: stability, longevity, mature, well-adopted, proven in a WordPress context, accommodating to accessibility requirements, interoperability with existing code, architected to support predictable data flows and composability, alignment with efforts like Calypso,  composable, extensible, testable and ease of developer adoption.

@kopepasah promoted Vue.js, saying he found it “much more approachable and highly extensible” and also “Vue single file component is amazingly organized and easy bundle and build.” See https://vuejs.org/v2/guide/single-file-components.html.

@rmccue pointed out that the React core development philosophies match up to ours quite well: https://facebook.github.io/react/contributing/design-principles.html

@afercia raised accessibility and wanted to know which framework was best suited to offer support, specifically in handling cases where direct DOM access and manipulation is needed.

@aduth shared the reasoning behind the choice of React for the Gutenberg project: https://github.com/WordPress/gutenberg/tree/master/element#why-react

As anticipated, the decision was not settled in the meeting and discussion will resume in next week’s meeting. Currently, React appears to be the favored candidate. Please add to the conversation in the comments below, and join us for further discussion at our next meeting, scheduled for May 30, 2017 at 13:00 UTC

For the full meeting notes, see the Slack logs.

#javascript, #summary

JavaScript Chat Agenda for May 23rd

Please join us for our weekly JavaScript Chat on May 23, 2017 at 13:00 UTC, where we will discuss:

  • Introducing a module pattern for WordPress JavaScript, see #40834.
  • A framework for future WordPress JavaScript. What are the goals and criteria for making a decision, and what do we hope to get out of it? To specific frameworks, which options are we considering, and who can share their experiences in implementing them in the context of WordPress? Finally, how do we make decisions about ongoing development and maintenance of existing Backbone-based features? Note: this discussion item may take more than one meeting.
  • Open floor

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#agenda, #javascript

JavaScript Chat Summary for May 16th

Below is a summary of the conversation from today’s JavaScript Chat (agenda, Slack archive):

Build Tools for Code Standards

  • There’s a desire to replace the current JSHint configuration with an ESLint solution (#31823)
  • @netweb shared a number of ESLint-related projects targeting parity with existing JSHint and JSCS configuration
  • JSHint was mainly designed to identify potentially erroneous code. ESLint builds upon this with support for style and custom rule enforcement
  • What steps do we then take to extend the ruleset to meet the remainder of the JavaScript Coding Standards? Parity with .jshintrc has the benefit of serving as a drop-in replacement, but legacy code and existing patches may be impacted by broader rule enforcement.
  • Options for incremental adoption of rules: first configure rules as warnings, or attempt to lint only lines modified in proposed change (as in PHPCS, or Calypso’s git-based eslines)
  • Alternatively, forgo incremental adoption and instead make a single pass to fix offending code, using ESLint’s fixer or prettier (discussion ticket to be created), at the cost of potential disruption to existing patches by conflicts introduced. This appears to be the favored path.
  • How do we reconcile a desire to retroactively fix coding offenses with our guidelines explicitly forbidding this sort of refactoring? The guideline was revised with an ending note about internal consistency. @jorbin later remarked that exceptions have been made in the past for allowing JSHint-based refactoring.

General Remarks on JavaScript Standards

  • @aduth raised a concern of the difficulty in following spacing exceptions on function arguments, arguing that the mental overhead in understanding how context varies application of the rule could explain why it’s followed inconsistently.

Tickets

  • @adamsilverstein requested feedback on a ticket proposing to make two utility functions specific to Press This more widely available (#40635)

Open Discussion

  • A meeting topic was proposed: Module patterns to extend or replace Browserify and make internal utilities more broadly available. Special attention will need to be made for interoperability with existing patterns for declaring script dependencies.
  • A meeting topic was proposed: Making a decision on a framework to use in place of Backbone, based on consensus from last week that a replacement is needed.

#javascript, #summary

JavaScript Chat Agenda for May 16th

Join us for our weekly JavaScript Chat on May 16, 2017 at 13:00 UTC, where we will discuss:

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#agenda, #javascript

JavaScript chat summary for May 9th

The focus of the meeting was reflecting on ongoing and past efforts to apply JavaScript more heavily in WordPress, to help inform requirements of the tools we’ll need to implement the features we want to build.

To the end of better understanding what we have in core now, @adamsilverstein shared some research he is working on: A slidesdeck of JavaScript added to each version of WordPress (click the right arrow on the first link to go thru the versions) and a summary of features that use JavaScript added to each version

Next, we delved into the pains, tools, patterns, etc. used in the following ongoing efforts:

  • Porting the media library and TinyMCE into the Customizer with Media and Text widgets
  • Creating new and revised UIs leveraging the REST API like Quick Drafts and New List Table

@timmyc talked about his experiences developing the new Media Widgets, which are all built utilizing wp.media. @westonruter has created a great summary of some of the bumps they had along the way.

@youknowriad shared the experience working on the editor project using React. He said the main pain point is making TinyMCE work in a “controlled” way (unidirectional data-flow).

@rmccue and the REST API team have been looking at making the dashboard use the REST API generally, looking at a lot of the core JS. He summarized “WordPress has a JavaScript framework already: we have all the pieces that you’d have in a framework, but they’re not tied together, and they’re very poorly documented… Additionally, every piece is subtly different in architecture, implementation, design, etc.”

@joemcgill added the overall architecture of wp.media is not well documented anywhere, so there’s a huge barrier to entry for anyone who wants to work on even minor bugs. It’s not simply understanding backbone, but you also have to understand how wp.media has implemented a custom frame/region/state model.

The team agreed to work on documenting the overall wp.media architecture, and @omar offered to try to focus the team at Yoast on helping with documenting wp.media as part of their ongoing effort to document core JavaScript.

Discussion continued around the reason developers find working with media and other core JS so difficult. Is it the complexity? The lack of documentation? Or is the architecture itself the problem? Probably all of the above.

The discussion touched on the history and evolution of our use of JavaScript in core, and the consensus was that moving forward, new view/UI components should be built in a more modern framework such as React or Vue. The specific framework is a conversation for another day, the decision was that we need something new to be able to achieve the experiences we want to build. At the same time, we need to maintain what we have and ensure developers can use it. There was some discussion of core documentation and a proposal to add JSHint to core’s build process.

Discussion continued to backward compatibility, and the issue of “losing” PHP hooks when we switch old functionality from wp-ajax to the REST API. Do we need to provide backward compatibility for all PHP hooks? Or can we offer new approaches for developers to extend WordPress, for example, wp.hooks?  @omar shared their experience at Yoast when they switched their content analysis from php to js.

The meeting wrapped up with ideas for next week’s meeting the team made a plan to discuss modularity/modules as well as JavaScript coding standards.

As a reminder to contributors that there are over 300 open tickets in the JS focus that can use your help!

For a full transcript of the meeting, check the slack logs.

#javascript

JavaScript Chat Agenda for May 9th

Join us for our weekly JavaScript Chat on May 9, 2017 at 13:00 UTC, where we will discuss:

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#agenda, #javascript

JavaScript Chat Summary: May 2nd

The first-ever JavaScript Chat took place today (agenda, Slack archive). Below is a summary of the conversation:

Meeting Goals

  • Identify common requirements and ensure consistency between individuals and projects making heavy use of JavaScript in core
  • Discuss what must be provided as the “base” APIs to provide similar functionality in the browser as what’s available in PHP
  • Decide patterns and tools / frameworks to accommodate modern and future requirements
  • Understand how plugins and themes plan to use the browser context to avoid conflicts and incompatibilities

Tickets

The following tickets were discussed, chosen as having most immediate impact:

Actions and Filters

  • An effort to mirror PHP extensibility in the browser by providing hooks to transform data and take action in response to specific events
  • Consistency with PHP equivalents can improve developer experience by providing familiar tools, but we should be sure that the paradigms apply well across the languages
  • Worries
    • Are there special considerations for asynchronous coding patterns prevalent in JavaScript?
    • Do we first need to better outline how we expect data to be structured and managed in the client before deciding on transformation APIs?
  • Alternatives
    • Hyper.is extensions apply themselves as decorations, or intervene as middlewares in the application’s data flow
    • Reactive programming styles with observables (spec proposal, RxJS)
  • A side-exploration of data modeling requirements was raised, with a general desire to encapsulate state (perhaps in a single store) and provide options to inspect data and apply modifications at specific entry points. This should be able to be adopted incrementally, rather than as a full rewrite.

Date Handling

  • Ticket patch provides basic date formatting and localization on a wp.date global, matching those available in PHP (format, date, gmdate, date_i18n)
  • Non-controversial and ideally merged soon
  • Current proposed patch uses Moment.js, but interface does not bind us to it
  • We may want to consider future compatibility with overlapping browser APIs, such as DateTimeFormat. However, these implementations are browser-specific and compatibility with the date format site setting can’t always be guaranteed.

Internationalization

  • We need gettext support in the browser
  • How do we make strings available in the browser
    • By passing strings in HTML via wp_localize_script?
    • Asynchronously through REST API endpoints?
    • Probably best to stick with simpler approach to start (passed in HTML)
  • Need to consider build tools to extract strings from JavaScript
    • PHP solutions may not be future compatible with the frequently changing JavaScript language specification. This is a solved problem with JavaScript parsers tending to follow closely to the bleeding edge.

General

Please join us when we meet again next week at the same time. In the meantime, there are many tickets in the Trac JavaScript focus that can use help! https://core.trac.wordpress.org/focus/javascript

#javascript, #summary

Announcing the first Weekly Core JavaScript Chat

Please join us tomorrow Tuesday May 2nd at 13:00 UTC for the inaugural Weekly Core JavaScript Chat.

The following is the meeting agenda:

  • Discussion of goals of Weekly JS meetings – whats next for JavaScript in core?
  • Ticket discussion:

What goals or topics do you think deserve discussion? Add your ideas in the comments below.

#javascript

Proposal for Weekly Core JavaScript Chat

In last week’s core dev chat, @rmccue identified a need to coordinate on consistent approaches to common JavaScript requirements. As the projects of this year’s focuses have more heavily leveraged JavaScript, a few specific needs have arisen:

To coordinate work towards a common goal for JavaScript in core, we are planning weekly Core-JavaScript meetings to take place in the #core Slack channel. Proposed times for the meeting are (weekly at): April 26, 2017 at 00:00 UTC, April 26, 2017 at 01:00 UTC or April 27, 2017 at 02:00 UTC. @adamsilverstein and @aduth were nominated to lead the effort.

Additional topics may include:

  • Media Manager extensibility (#40427).
  • Modernization of tooling, patterns, and frameworks to accommodate heavier usage of JavaScript.

Comment with your interest and availability for the proposed meeting times below.

#javascript

JavaScript Internationalization

Prequel

Over the last few releases, WordPress has made huge steps in prioritizing internationalization and localization throughout around core. To name a few highlights: language packs for core, language packs for plugins and themes, a language chooser, just-in-time loading for translations, and a user-specific language setting. But core isn’t the only place improvements have been made.

translate.wordpress.org is the platform for making WordPress available in as many languages as possible. Did you know that WordPress 4.6 is currently translated into 72 – s e v e n t y t w o – languages? Recently the number of unique translators passed the 10k mark. 🌎🌍🌏

The platform is powered by GlotPress, a collaborative, web-based software translation tool.

Internationalization is not a feature, it fixes a usability issue for many users whose primary language is not English. And that’s about 47% of our users.

The next big thing

As of today, WordPress doesn’t support a proper internationalization API in JavaScript. There are two, 4-year old tickets, #22229 and #20491, which request such an API. (The former one was closed as a duplicate of #20491 since an internationalization API in JavaScript should provide support for plurals by default.)

And that’s what this post is about: JavaScript Internationalization.

@swissspidy and I (@ocean90) have been thinking about and working on this topic, and now is the time to gather feedback on the direction and get help from everyone interested.

As you may have noticed in the prequel, internationalization spans more than WordPress core. We’ve split the task into four areas: Core, GlotPress, wp-i18n-tools, and language packs.

Jed and wp.i18n (Core)

Since we didn’t want to reinvent any wheels, our proposal is to use Jed as the base library. Jed provides “Gettext Style i18n for Modern JavaScript Apps”.

wp.i18n will be a wrapper for Jed and should be used by WordPress and plugins/themes. One of the biggest benefits of leveraging Jed is that the actual implementation is very similar to the one we already have for PHP code. The latest patch currently introduces these API functions:

  • wp.i18n.getLocale()
  • wp.i18n.loadLocaleData( data )
  • wp.i18n.addTranslations( domain, data )
  • wp.i18n.__( text, domain )
  • wp.i18n._x( text, context, domain )
  • wp.i18n._n( single, plural, number, domain )
  • wp.i18n._nx( single, plural, number, context, domain )
  • wp.i18n.esc_attr__( text, domain )
  • wp.i18n.esc_html__( text, domain )
  • wp.i18n.esc_attr_x( text, context, domain )
  • wp.i18n.esc_html_x( text, context, domain )
  • wp.i18n.numberFormat( number, decimals )
To do
  • Rethink WP_Scripts::load_translation_file() and get_js_i18n_data(), add tests.
  • Get feedback on the proposed API. (That’s this post!)
  • Apply the new API in our JS files.
    • There’s a POC patch that can be worked upon.
    • Do not forget: Underscore templates.
  • Include date of json files in update requests for language packs.
    • See wp_get_installed_translations().
    • See wp_get_json_file_data(), maybe json_decode() might be enough for this case.
    • What’s the format for meta data? See this GitHub issue for discussion.
  • sprintf() in JavaScript – useful for core?

GlotPress (translate.wordpress.org)

Jed supports JSON for translation files. GlotPress currently doesn’t support exporting translations in a JSON format. But there is a pull request which adds the required functionality to GlotPress. The format is going to support “simple” JSON (key -> value) and a Jed 1.x compatible format. The latter will be used by wp.i18n.

To do
  • Get the PR merged. Done. 🎉
  • Find a solution for the missing meta data, see the GitHub issue mentioned before.
  • To enable exports like “get all translations for file common.js”, the current filter system in GlotPress needs to be improved to support search only in file references and search for multiple file references.

wp-i18n-tools (Meta)

A script named MakePOT parses PHP files to extract the original strings and their file references. This script needs to be extended to also parse JavaScript files. A POC has been created.

To do
  • Convert the POC into nice code with tests.
  • Fix #20881 because it’s important for the GlotPress export that all file references remain.

Language Packs (Meta)

Currently a language pack includes a .po and a .mo file. Support needs to be added so that a .json file gets bundled if a project has translations for JavaScript files.

To do
  • Export Jed files when JS translations exist.
  • Include JSON file in language packs.
  • Update API to support version checks for JSON files.

Feedback

Thanks for reading, now it’s your turn. 🙂 Do you have any feedback? Are there things we should do differently? Do you have resources to help us? Please let us know in the comments!

There are currently no meetings scheduled but we’re happy to discuss any topics in #core-i18n. Just say “Hi”!

#i18n, #javascript