JavaScript Chat Summary: April 7, 2020

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. chat (agenda, Slack Transcript).

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

Consent APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.

(Slack conversation)


Feature Proposal:

Discussion: What is the ideal JavaScript interface for accessing, updating, and responding to changes in consent? In what ways could we leverage the existing data module?

Discussion Points:

  • Is data module supported on sites running Classic Editor pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the Plugin Directory or can be cost-based plugin from a third-party? Is it otherwise tied to the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor?
    • While it is developed in the 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. repository, it’s intended to be general-purpose to support a variety of use-cases.
    • For example, WooCommerce plugin is using the data module outside of the editor context.
  • A primary value of the data module is API consistency in retrieving and updating data.
  • There is a need to support expiration as part of the requirements of the Consent API.
    • @nerrad has done some experimentation around this and would be happy to help contribute to the discussion.
  • @youknowriad shared a code example for how a basic consent implementation could be achieved using the data module.
  • There could still be abstractions on top of the data module.
    • For example, the blocks module uses the data module internally, but still exposes its public API as wp.blocks.registerBlockType, etc.
    • Ideally these would still follow the convention of groupings under the wp global (wp.consent).
  • Another advantage of the data API is that it provides future-proofing if blocks or future UIs are built with the Consent API in mind.
  • There’s a general desire to develop new APIs as following consistent and established patterns.
  • There may need to be enhancements to the data module in order for it to be most useful:
    • Subscribing to changes in a specific store value is currently cumbersome.
    • Expiration.
    • Persistent storage using cookies.
      • The current data module or persistence implementation can support this, but it may still need further enhancements so as not to break expectations that preferences may still need to save to localStorage for the near future.

#core-js, #javascript