Quantcast
Channel: Issues for Drupal core
Viewing all articles
Browse latest Browse all 294402

Settings Tray provides functionality, not an API: mark everything (PHP+JS+CSS+HTML) as @internal

$
0
0

Problem/Motivation

It looks like there's quite a bit of refactoring of logic/code still planned for the Settings Tray module.

Before BigPipe was marked stable, we marked all classes & interfaces @internal, because BigPipe provides only functionality, not APIs.

I think that you probably want to do something similar for Settings Tray? I think you want to limit the API surface in a very clear, very simple way:

Any block that provides an off_canvas form in their block plugin annotation, is automatically picked up.

(Plus probably something for making things other than blocks configurable via the Settings Tray.)

Proposed resolution

  1. Mark as much as possible as @internal. That would include all PHP code, all HTML (Twig templates), all JS, all CSS. The only thing that's an API, is the declaration of "off_canvas forms".
  2. Add a outside_in.api.php file to document the actual API.

(And yes, off_canvas should be renamed to settings_tray, but that's probably part of #2803375: Rename Outside-in module to "Settings Tray" for real.)

Remaining tasks

TBD

User interface changes

None.

API changes

None.

Data model changes

None.


Viewing all articles
Browse latest Browse all 294402

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>