Skip to content

Evaluate approaches to enable sticky headers for GLQL embedded tables

Problem

GLQL embedded table views don't have sticky headers, causing users to lose context when scrolling through datasets. Users can't see:

  • Which table they're viewing (panel title)
  • Column headers that identify what data they're looking at
  • Access to table controls (collapse/expand, actions menu)

This is particularly frustrating when working with large query results where users need to scroll extensively.

Current State

GLQL tables use custom Vue components with a presenter architecture (app/assets/javascripts/glql/components/presenters/) rather than Pajamas Design System components. This architecture was likely chosen for valid reasons during GLQL's rapid development (6 months from concept to GA):

  • Performance optimization and bundle size management
  • Flexibility for GitLab-specific object rendering (labels, users, health status with popovers)
  • Development velocity to meet aggressive timelines

However, this makes implementing sticky headers more complex. Browser limitations with position: sticky on standard table layout (display: table-header-group) prevent straightforward CSS solutions for making table column headers sticky.

Desired Outcome

Users can scroll through GLQL table data while maintaining visual context:

  • Panel header remains visible (table title, controls)
  • Table column headers remain visible (data column names)
  • Headers stack properly with other sticky elements (work item headers, MR headers)

Why This Matters

When analyzing data in GLQL tables, users frequently need to scroll through many rows.

Without sticky headers, they lose track of what they're looking at, how to interact with the data, and context for decision-making.

This forces users to scroll back and forth repeatedly, slowing down their workflow:

Current implementantion
CleanShot 2025-10-20 at 14.45.42.mp4

Technical Context & Questions

GLQL's current custom Vue component architecture was likely chosen for specific technical reasons during the rapid 6-month development cycle. We should understand:

  • What were the original reasons for using custom components instead of Pajamas table components?
  • Are there technical approaches to enable sticky headers within the current architecture?
  • If migrating to Pajamas components, would the custom presenter architecture work within that system?
  • What are the performance and bundle size implications of different approaches?
  • Are there accessibility gaps in the current implementation that should be addressed alongside sticky headers?

Next Steps

  1. Gather input from engineering on feasible approaches
  2. Evaluate technical trade-offs (performance, maintainability, accessibility)
  3. Scope implementation effort for recommended approach
  4. Test proposed solution with users to validate it solves the context loss problem

Related Work

Edited by 🤖 GitLab Bot 🤖