.table-wrapper {
width: 100%;
overflow-x: auto;
-webkit-overflow-scrolling: touch;
}
.data-table {
width: 100%;
border-collapse: separate;
border-spacing: 0;
}
.data-table th:first-child,
.data-table td:first-child {
position: sticky;
left: 0;
background-color: var(--bg-surface);
z-index: 2;
box-shadow: 2px 0 5px rgba(0, 0, 0, 0.08);
}Dashboard-urile pe mobil sunt coșmarul oricărui frontend dev când stakeholderul vrea „totul exact ca pe monitorul de 27 de inch”. Am trecut prin asta anul trecut la un SaaS B2B cu vreo 1.400 de utilizatori activi zilnic, unde jumătate din manageri verificau rapoartele de pe telefon, din mers. Soluția n-a fost să înghesui datele, ci să aplic trei pattern-uri clare care nu sacrifică lizibilitatea.
Sidebar-ul: ascuns complet pe mobil, nu doar „icon-only”
Pe desktop e comod să ai un sidebar extins de 260px pe care să-l restrângi la 64px cu iconițe. Mulți încearcă să lase varianta icon-only și pe ecrane de telefon. E o greșeală clasică. Pe un ecran lat de 390px, 64px de iconițe mănâncă 16% din spațiul orizontal de pomană, iar target-ul de touch devine înghesuit.
Abordarea corectă: pe viewport sub 1024px, sidebar-ul iese complet din fluxul documentului. Devine un drawer absolut/fixed, ascuns în stânga (transform: translateX(-100%)), declanșat doar de burger menu cu un overlay negru translucid în spate. Pe desktop folosești CSS Grid clasic, iar la breakpoint schimbi pur și simplu layout-ul din grid cu două coloane într-un layout pe o singură coloană.
Trade-off sincer: dacă ai animații complicate la deschiderea drawer-ului, pe Android-uri mai vechi riști să ai frame drops. Rezolvarea e simplă: transform și opacity, fără să animezi lățimea (width).
Tabele mari: scroll orizontal ghidat, nu transformare forțată
Toată lumea recomandă pe tutoriale să transformi table în carduri pe mobil folosind display: block pe td și pseudo-elemente ::before cu label-ul coloanei. Să fim serioși: la un tabel de facturare cu 14 coloane și 40 de rânduri, varianta asta generează o pagină infinită. Nimeni nu poate compara valori pe verticală când fiecare rând devine un card de 400px înălțime.
Ce a funcționat mult mai bine la noi: am păstrat structura nativă de tabel, dar l-am băgat într-un wrapper cu overflow-x: auto și position: sticky pe prima coloană (de regulă numele clientului sau ID-ul). Adaugi o umbră subtilă pe marginea dreaptă a primei coloane, ca utilizatorul să vadă clar că restul tabelului trece pe sub ea când dă swipe.
Minusul abordării? Safari pe iOS are un bug vechi legat de position: sticky aplicat pe celule de tabel dacă ai border-collapse: collapse. Trebuie să treci pe border-collapse: separate și border-spacing: 0, altfel border-urile dispar sau tremură la scroll.
KPI Cards: container queries sau auto-fit
Pentru metricele de sus (cele 3-4 carduri clasice cu MRR, Churn, Active Users), regula e să nu te complici cu 10 media queries. Un CSS Grid cu repeat(auto-fit, minmax(220px, 1fr)) rezolvă 95% din cazuri fără niciun breakpoint setat manual.
Pe telefoane înguste cardurile pică natural pe o singură coloană, pe tablete devin două pe rând, iar pe ecrane ultrawide ocupă uniform spațiul disponibil. Dacă textul din card e foarte lung, poți folosi Container Queries (container-type: inline-size) direct pe card, astfel încât fontul cifrelor să scadă automat doar când cardul respectiv se îngustează, indiferent de dimensiunea întregului ecran.
Voi cum abordați tabelele financiare stufoase pe mobil? Preferați scroll-ul orizontal cu coloană fixă sau deschideți un modal detaliat la tap pe fiecare rând?