Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

6.7 Dev Note Tracking Issue #65784

Open
fabiankaegy opened this issue Oct 1, 2024 · 16 comments
Open

6.7 Dev Note Tracking Issue #65784

fabiankaegy opened this issue Oct 1, 2024 · 16 comments
Assignees
Labels
[Type] Developer Documentation Documentation for developers [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues.

Comments

@fabiankaegy
Copy link
Member

fabiankaegy commented Oct 1, 2024

Tracking all Dev Notes from Gutenberg plugin releases 18.6 - v19.3

Please read the information below carefully. If you have questions or suggestions, connect with @fabiankaegy via Slack, ping @fabiankaegy on GitHub, or comment here.

Important

🗓 Deadline Drafts for All Dev Notes - October 13th, 2024 (a few days before Beta 3, so there's enough time for reviews)
🗓 Deadline All Dev Notes Published - October 20nd, 2024 (a few days before RC1)

Not all developer-related information must be in a separate DevNote on the Make Core blog for the field guide. We can group related information. We can already decide whether some features warrant a stand-alone blog post or a group post.

Stand-alone post

To streamline the process and eliminate bottlenecks, all writers of stand-alone dev notes will write the dev notes on the Make Core Blog.

Instructions
  • Create your note in a new post,
  • Save as Draft
  • Enable public preview
  • Share the link to the public preview in a comment below as "ready for review"
  • "For dev notes, each one must have at least two reviewers" (Handbook)

Part of a group post

If the information related to your PR will be part of a group post, please write the dev note in a comment on the PR, so it can be reviewed and, if necessary commented on, by the release docs team or a reviewer.

Before you start writing 📣 please read the handbook pages:


Note

The list is incomplete. We are in the process of reviewing plugin release changelogs and add them as we progress on the task.

There are two labels relevant to DevNotes :

If you worked on a feature/module/component that definitely needs a dev note, please assign the label needs dev note If you already added the Dev Note to the make blog on draft or as a comment on the PR, please label it has dev note


TO DO

Progress of the Documentation work for WP 6.7 release (including the DevNotes tracked on this issue) can also be followed at WP 6.7 Documentation project dashboard

PRs with label has-dev-note or a related DevNote draft are marked with [x]

Standalone Posts:

Stabilize Role Attribute Property ✅ - [Draft]
@youknowriad and @getdave have agreed to work on this one and already shared a Draft.

Zoomed Out Mode
I'd love to have one dev note dedicated to all things Zoomed out mode that explains the feature and how to work with it. Including how stuff like the "Section detection algorithm" work.

@getdave has volunteered to help triage this :) A draft is available at #64197 (comment)

Block Bindings
We should have a dedicated dev note for all things Block Bindings that talks about all the new stabilized API's etc. @cbravobernal can you help with this?

Interactivity API Updates
@DAreRodz or @michalczaplinski , can you help with this?

Components Package Updates

@mirka @ciampo have volunteered to help with this :)

Miscellaneous Editor Updates (TBD)

Miscellaneous Core Updates (TBD)

Query Loop Updates
@ryanwelcher would you be able to help write a dev note for these changes?

Consolidating and expanding block supports
@mumtahinafaguni Would you be able to draft a dev note that includes all these updates in one post? 🤔

@fabiankaegy fabiankaegy added [Type] Developer Documentation Documentation for developers [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues. labels Oct 1, 2024
@talldan

This comment was marked as resolved.

@fabiankaegy

This comment was marked as resolved.

@talldan

This comment was marked as resolved.

@youknowriad

This comment was marked as resolved.

@fabiankaegy

This comment was marked as resolved.

@matiasbenedetto

This comment was marked as resolved.

@fabiankaegy

This comment was marked as resolved.

@matiasbenedetto
Copy link
Contributor

matiasbenedetto commented Oct 1, 2024

It is an end user feature but I think developers should be aware of it.

Gotcha 👍 , here it goes:


Font Size Presets UI

A new UI feature has been introduced in the Global Styles section of the editor, allowing users to add, edit, and remove font size presets.

A font size preset is a predefined font size that can be reused throughout the site via the font size picker. This enhancement provides a more user-friendly way to manage font size options, which were previously only accessible via the manual edition of theme.json file. Users can now modify preset names, base sizes, enable or disable the default fluid behavior, and customize the minimum and maximum values for fluid font size presets directly from the UI.

To access this interface, navigate to the Styles sidebar, then go to Typography → Font Sizes.

@cbravobernal
Copy link
Contributor

@artemiomorales started an initial draft of the dev note for block bindings 🚀

@swissspidy
Copy link
Member

swissspidy commented Oct 2, 2024

I am confused. Is this ticket about Gutenberg dev-notes or all dev-notes for 6.7? There are tickets mentioned in here that have nothing to do with Gutenberg.

In the past, for the dev-notes a separate project board was used (e.g. https://github.com/orgs/WordPress/projects/202). Not an issue in the Gutenberg repo... That's super confusing and can lead to false impressions.

Edit: I see now there is a board for 6.7 as well. So why mention regular trac tickets in here that are completely unrelated to Gutenberg? Are contributors supposed to work here, or on the board?

@DaniGuardiola
Copy link
Contributor

DaniGuardiola commented Oct 2, 2024

Hi @fabiankaegy, responding to #64943 (comment) here :)

I think the dev notes could go like:


New useEvent utility in @wordpress/compose

The new useEvent utility creates a stable callback that has access to the latest state (as opposed to a useCallback call with an empty dependency array). This is useful to "untrack" dependencies in a callback that is called within event handlers or effects. It cannot be called at render time.

This is a common pattern in React, and it's even being considered as a core React feature (see the RFC). More context can be found in this popular issue in the React repository.

Here's an example:

 function Component( props ) {
   const onClick = useEvent( props.onClick );
   useEffect( () => {
     onClick();
     // Won't trigger the effect again when `props.onClick` is updated.
   }, [ onClick ] );
   // Won't re-render `Button` when `props.onClick` is updated (if `Button` is
   // wrapped in `React.memo`).
   return <Button onClick={ onClick } />;
 }

New useResizeObserver API in @wordpress/components

The new API and behavior of useResizeObserver is meant as a thin wrapper for the browser-native ResizeObserver API, which enables more use cases and better composition. The previous API is still supported, though it is considered legacy and deprecated.

Now, you must pass a callback as the first argument to the hook which is forwarded to the ResizeObserver constructor. The hook returns a setter that must be passed as a callback ref to the target element, or called in an effect in advanced use-cases. Additional options for the internal ResizeObserver.observe call can be passed as the second argument.

Here's an example:

const setElement = useResizeObserver(
  ( resizeObserverEntries ) => console.log( resizeObserverEntries ),
  { box: 'border-box' }
);
<div ref={ setElement } />;

// The setter can be used in other ways, for example:
useLayoutEffect( () => {
  setElement( document.querySelector( `data-element-id="${ elementId }"` ) );
}, [ elementId ] );

Let me know if that works! :)

@fabiankaegy
Copy link
Member Author

I am confused. Is this ticket about Gutenberg dev-notes or all dev-notes for 6.7? There are tickets mentioned in here that have nothing to do with Gutenberg.

In the past, for the dev-notes a separate project board was used (e.g. https://github.com/orgs/WordPress/projects/202). Not an issue in the Gutenberg repo... That's super confusing and can lead to false impressions.

Edit: I see now there is a board for 6.7 as well. So why mention regular trac tickets in here that are completely unrelated to Gutenberg? Are contributors supposed to work here, or on the board?

Sorry for the confusion @swissspidy. That is completely on me.

I had attempted to get one single source of truth for all the dev notes in this tracking issue to try and help make it less confusing for the team working on actually triaging the Dev Notes. But I realize how that may add more confusion as it is not respecting the lines of the different parts of the project.

I will update this ticket here to again be only editor focussed and move the "Core" items to the project board. I may need a day to get back to this but you can safely ignore this ticket for now 👍

@jasmussen

This comment has been minimized.

@ndiego

This comment has been minimized.

@sgomes
Copy link
Contributor

sgomes commented Oct 3, 2024

As of #64981, the Media & Text block now uses an img element instead of using CSS background-image when the "Crop image to fill" option is enabled, removing the last usage of background-image in this block. This means that, when rendering the post, all the usual performance benefits of using image elements will now be applied, such as having the image load lazily when appropriate, and letting the browser choose the most appropriate image size from the list of generated sizes.

Please feel free to rephrase as needed! 👍

@ntsekouras
Copy link
Contributor

Regarding #64872 I think it will work best if we have a paragraph for related small enhancements.

A parent block's style variations are now surfaced for contentOnly locked groups. This way styles can still be applied cohesively across the group of blocks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Developer Documentation Documentation for developers [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues.
Projects
None yet
Development

No branches or pull requests