Adaptive Grid Layout Solutions for Management Backend Pages

Background

In backend management pages, card‑list displays are common but face two main issues: inconsistent PC resolutions (e.g., 1920 px, 1366 px, 1600 px) and the impossibility of providing multiple design drafts for every breakpoint.

Problems before optimization

(1) PC resolution is not uniform

Users open the admin console with various browser widths, and sometimes shrink the window for other tasks. Layout must accommodate a wide range of screen widths.

(2) A single design draft

Designers cannot create many drafts for every device; a lightweight, universal solution is needed.

Existing simple solutions

Two common approaches are used:

Fixed card width – leads to large empty spaces when the window is resized.

Fixed number of cards per row – causes cards to become overly large or tiny on extreme widths.

Layout scheme analysis

We classify layout elements into three factors: card width, card margin, container padding . Adaptive grid layout dynamically adjusts these three factors.

Industry solutions

Google Material Design – divides page width into 13 breakpoints and adjusts the three factors at each breakpoint. Suitable when the product follows Google’s UI guidelines and does not require later customization.

Custom grid scheme – used by corporate sites and video platforms; multiple design drafts are prepared for different resolution intervals. Works when design resources are abundant.

Adaptive grid scheme – uses a calculation formula to derive one factor from the other two, requiring minimal design resources while delivering good visual results.

Adaptive scheme summary

Material Design: best for teams with few design resources and a fixed Google‑style UI.

Custom grid: best for teams with rich design resources and strong customization needs.

Adaptive grid: best for teams with limited design resources that still want a personalized grid style.

Our team chose the adaptive grid scheme and implemented it as a reusable component.

Adaptive Grid Component Implementation

The component consists of a Grid container and GridItem cards. It supports four basic configuration items and three custom options.

1. Component usage

Example usage in a project list:

<grid ref="grid" :gridType="'autoMargin'" :baseW="250">
<grid-item v-for="project in projectList" :key="project.projectId" class="project-item">
<div class="name">{{ project.name }}</div>
</grid-item>
</grid>

2. Core logic

On mounted , listen to window.resize .

When the window width changes, clear previous calculations and recompute the adaptive layout.

Before component destruction, remove the resize listener.

mounted () {
window.addEventListener('resize', this.calcGridSize, false)
this.reset()
},
beforeDestroy () {
window.removeEventListener('resize', this.calcGridSize, false)
},
methods: {
reset () {
// clear calculation data
this.calcGridSize()
},
calcGridSize () {
// recompute layout
}
}

3. Adaptive calculation

Three schemes share the same core: based on three numeric configuration items, compute how one factor adapts when the page width changes.

For the “auto‑card‑width” scheme, the calculation flow is:

Determine the calculation method based on gridType .

Compute the number of cards per row ( gridNum ).

Use limitW to decide whether to adjust the card count and finally derive gridW .

calcGridSize () {
// step 1, choose calculation method
if (this.gridType === 'autoMargin') {
this.calcAutoMg()
} else if (this.gridType === 'autoPadding') {
this.calcAutoPd()
} else {
this.calcAutoWd()
}
},
calcAutoWd () {
const containW = this.$el.clientWidth
const { baseMg, baseW, limitW } = this
// step 2, calculate grid count
const caclW = containW - baseMg
let gridNum = Math.floor(caclW / baseW)
let gridW = caclW % baseW / gridNum + baseW - baseMg
// step 3, adjust if needed
if (caclW % baseW > limitW) {
gridW = caclW / (1 + gridNum) - baseMg
}
this.gridW = gridW
},

4. CSS variable based style transfer

We use CSS custom properties (variables) to pass calculated values from the parent Grid to child GridItem components.

<style>
.grids {
--gridW: 200px;
}
.grids .grid-item {
width: var(--gridW);
height: var(--gridH, 50px);
}
</style>

Variables are defined with a double hyphen (e.g., --gridW ) and accessed via var(--gridW) . They inherit the cascade rules of normal CSS.

Compatibility is good across modern browsers, as confirmed by CanIUse data.

Component template example (using CSS variables)

<template>
<div class="grids" :style="{ '--gridW': gridW + 'px', '--gridMg': gridMg + 'px', '--gridPd': gridPd + 'px' }">
<slot></slot>
</div>
</template>
<script>
// ...
</script>
<style lang="less" scoped>
.grids {
overflow-y: auto;
display: flex;
flex-wrap: wrap;
justify-content: flex-start;
align-content: flex-start;
padding: 0 var(--gridPd) 0 calc(var(--gridPd) - var(--gridMg));
>>> .grid-item {
width: var(--gridW);
margin-left: var(--gridMg);
}
}
</style>

Conclusion

We analyzed current layout problems, surveyed industry solutions, implemented an adaptive grid component, and optimized it with CSS variables. This approach improves card‑list displays in management back‑ends, adapts to various screen widths, and reduces design overhead.