Feature Request: Programmatic Viewport Access in UI Extensions

Extensions
,
1

The Problem

Currently, UI Extensions only provide MaybeResponsiveConditionalStyle props for responsive behavior. This approach has major limitations:

Performance Issues: We’re forced to render multiple component trees just for simple changes:

// Current inefficient approach
<View display={{ 
  default: 'block', 
  conditionals: [{ conditions: { viewportInlineSize: { min: 'small' } }, value: 'none' }] 
}}>
  <ComplexComponentTree />
</View>
<View display={{ 
  default: 'none', 
  conditionals: [{ conditions: { viewportInlineSize: { min: 'small' } }, value: 'block' }] 
}}>
  <SlightlyDifferentComplexComponentTree />
</View>

No Programmatic Control: There’s no way to know which viewport we’re currently on, preventing:

  • Device-specific navigation (app links on mobile, web links on desktop)
  • Conditional logic based on screen size
  • Different analytics/API behaviors per device

Proposed Solution

Add a useViewport() hook that works like window.matchMedia():

import { useViewport } from '@shopify/ui-extensions-react/customer-account';

function MyExtension() {
  const { current } = useViewport();
  // current: 'extraSmall' | 'small' | 'medium' | 'large'
  
  if (current === 'extraSmall') {
    return <MobileOptimizedComponent />;
  }
  
  return <DesktopComponent />;
}

Real Use Cases

Performance: Single render path instead of multiple trees

const config = current === 'extraSmall' 
  ? { columns: 1, showImages: false }
  : { columns: 2, showImages: true };

Smart Navigation: Route based on device

const handleClick = () => {
  if (current === 'extraSmall') {
    window.location.href = `some-native-app-link`; // Native app
  } else {
    window.location.href = `link-to-a-web-based`; // Web interface
  }
};

Device-Aware Analytics: Track with device context

analytics.track('product_viewed', {
  device_type: current,
  viewport_category: current === 'extraSmall' ? 'mobile' : 'desktop'
});

Why This Matters

This would solve fundamental performance and UX limitations while providing familiar, web-standard APIs. The current MaybeResponsive system forces inefficient patterns and prevents building truly responsive, device-aware extensions.

Would love to see this prioritized - it’s a common pain point for anyone building complex responsive UI extensions!

2

This is a fearure we’ve been waiting for long!!

3

Thanks for raising this @muchisx, we’ve found a need for exactly the same thing. One specific use case we had was wanting to present paginated lists of records with different numbers of columns based on viewport width. We don’t currently have any way of specifying a page size based on the viewport width meaning that we can’t load different numbers of records based on the number of columns we want to display, meaning that it’s very likely that we’ll load partial rows on some viewport widths – not a great UX.

4

This has been open for a while, and with the removal of viewport queries within UI Extensions, this requests becomes even more relevant.

Would it be realistic to add it to the roadmap ?