Identifying the current admin screen context

[mrleemon]

I am currently developing a block extension that needs to display an additional sidebar panel via InspectorControls. However, this panel is specifically designed for the widgets editor (wp-admin/widgets.php or the Customizer) and should not appear when the user is in the standard post/site editor.

Is there a selector in @wordpress/data that returns the current admin screen context?

[stokesman]

Is there a selector in @wordpress/data that returns the current admin screen context?

I’m doubtful there is.

It seems like the cleanest thing would be to enqueue your script conditionally with help from the current_screen action. Otherwise, in JS, maybe check the wp global for existence of editWidgets

if ('editWidgets' in window.wp) {/*…*/}

[MukundaKatta]

Expanding on @stokesman's direction — there are two reliable techniques and one new-ish selector, depending on how you want to gate the UI.

1. Check which editor's data store exists

Each editor registers its own store, and stores are registered only when that editor is actually running. So the truthy / falsy existence of these stores is the cleanest runtime signal:

import { select } from '@wordpress/data'

function getEditorContext() {
  if (select('core/edit-widgets'))      return 'widgets'      // wp-admin/widgets.php (block widgets screen)
  if (select('core/customize-widgets')) return 'customizer'   // Customizer → Widgets panel
  if (select('core/edit-site'))         return 'site-editor'  // Full Site Editor / hybrid theme
  if (select('core/edit-post'))         return 'post-editor'  // Gutenberg post/page edit
  return 'unknown'
}

Then gate your InspectorControls render:

const ctx = getEditorContext()
return (
  ctx === 'widgets' || ctx === 'customizer'
    ? <InspectorControls>…your panel…</InspectorControls>
    : null
)

This works in render_block extensions, BlockEdit HOC filters, and block-type filters — anywhere the data modules are available. The select(...) calls return undefined for a missing store instead of throwing, so no try/catch needed.

2. Enqueue the script conditionally on the server

The most efficient version of this is @stokesman's suggestion: don't ship the JS at all to contexts where it's not needed. The current_screen hook gives you the admin screen from PHP:

add_action( 'admin_enqueue_scripts', function ( $hook ) {
    $screen = get_current_screen();
    if ( ! $screen ) return;

    // Widgets block editor screen → widgets.php
    // Customizer runs on customize.php with screen->id === 'customize'
    $in_widgets_context = in_array( $screen->id, [ 'widgets', 'customize' ], true );

    if ( $in_widgets_context ) {
        wp_enqueue_script(
            'my-widgets-panel',
            plugins_url( 'build/widgets-panel.js', __FILE__ ),
            [ 'wp-blocks', 'wp-data', 'wp-hooks', 'wp-i18n', 'wp-block-editor' ],
            filemtime( plugin_dir_path( __FILE__ ) . 'build/widgets-panel.js' ),
            true
        );
    }
} );

This is what Core itself does for editor-specific assets — skip shipping the JS and the InspectorControls code never registers in the wrong context. Pair it with the JS guard above as defence in depth (the PHP guard can miss edge cases like third-party custom admin pages that embed the block editor).

3. useEditorContext or useSelect pattern for FunctionComponents

If your panel is mounted inside a block's Edit, the same detection works via hooks:

import { useSelect } from '@wordpress/data'

const isWidgetsContext = useSelect(
  (selectFn) => Boolean(selectFn('core/edit-widgets') || selectFn('core/customize-widgets')),
  []
)

if (!isWidgetsContext) return null

useSelect re-evaluates when the relevant store changes, so if a user navigates between editors in a SPA-like flow (rare but possible with certain admin workflows), the panel renders/unrenders correctly.

Caveat about hybrid themes

In a hybrid theme using the Site Editor for template parts while still serving classic widgets, core/edit-site will be present and core/edit-widgets is present on widgets.php. They don't co-exist on the same screen — each editor loads on its own admin page — so the "check which store exists" trick stays unambiguous. If you ever see both register at once, that's usually a third-party plugin initialising editors it shouldn't be; worth guarding with screen->id from PHP as the source of truth.

Why there's no single getCurrentScreen() selector

The editor stores are deliberately decoupled — core/edit-post doesn't know about core/edit-widgets, and vice versa. Adding a "what screen am I on?" selector would create a circular awareness between modules that Gutenberg has specifically avoided. The idiomatic "selector" is therefore "which store is registered?", which is what you're doing in option 1.

That said, there's been some discussion about a neutral context primitive for exactly this reason. If you want a single API, it's worth +1'ing that issue.