Skip to content

[repo:objectui] View tab bar caps visible tabs at a fixed maxVisibleTabs = 4 — 8 queues on a 1440 px page render 4 + '还有 4 个' with ~700 px of empty bar #14883

Closed as duplicate

Description

@baozhoutao

Summary

The object list page's view tab bar shows at most 4 view tabs regardless of available width. An object with 8 list views on a 1440 px viewport renders 4 tabs, then 还有 4 个 ({{count}} more), leaving roughly 700 px of the tab bar empty. The queues a role needs most (here: 待领导审批 / 已通过 / 已归档 / 流程看板) are hidden behind the overflow menu for every user, on every screen size.

Minimal reproduction

Platform 17.2.0 console, viewport 1440×900 (also 1920).

  1. Define an object with a list view plus 7 listViews (short 2–5-character Chinese labels; here 全部填报单 / 填报中 / 分公司核对中 / 待人力审核 / 待领导审批 / 已通过 / 已归档 / 流程看板).
  2. Open the object list page.

Measured in the page (DevTools, data-testid="view-tab-bar"):

viewport 1440 · tab-bar width 1152 px · parent width 1184 px
visible tabs: 全部填报单, 填报中, 分公司核对中, 待人力审核
overflow button: "还有 4 个"

The four visible tabs occupy ~430 px; the remaining ~720 px of the bar are blank.

Where

plugin-view chunk of the console — the tab bar component destructures its options with a fixed default:

let { showAddButton:S=!0, inlineRename:C=!0, contextMenu:w=!0, reorderable:T=!1,
      maxVisibleTabs:E=4, showIndicators:k=!0, ... } = i
...
{visibleViews:U, overflowViews:fe} = useMemo(() => {
  let e = H.slice(0, E), n = H.slice(E); ...

No ResizeObserver / width measurement participates; E is not set from view metadata anywhere I could find.

Expected

  • Overflow should be width-aware: fit as many tabs as the bar can hold (measure, or CSS container query), and only then collapse the rest into {{count}} more.
  • Or, at minimum, let the app author raise the cap from view metadata (e.g. a tabs.maxVisible / listViews display option), and raise the default well above 4 — most business objects have 5–8 status queues.
  • Keep the current behaviour (active tab promoted out of the overflow) — that part is fine.

Environment

@objectstack/console 17.2.0 via @objectstack/cli 17.2.0 · objectstack dev · Chrome. App: objectstack-ai/kpi, object kpi_entry_sheet.

Activity

  1. added
    bugSomething isn't working
    repo:objectuiSeam card: cross-repo ordering with objectui is the substance (pure objectui fixes live in objectui)
    on Sep 3, 2026
  2. added theissue type on Sep 10, 2026
  3. huangyiirene commented on Sep 10, 2026

    @huangyiirene
    Collaborator

    Triage: lands in objectstack-ai/objectui (list-page view tab bar) ⇒ repo:objectui; type Bug; priority:p2 unchanged; pm:queue.

    Rationale: a fixed maxVisibleTabs = 4 in the console's view tab bar is entirely an objectui concern — the report does not depend on objectstack in any way. It already carried repo:objectui; the missing piece was a state label, which is why it sat 6+ days outside every queue scan.

    Type Bug rather than Feature: the card's own measurement shows the bar is 1152 px inside a 1184 px parent and still collapses to 4 — the component has the width it needs and does not use it. That is a defect, ⛔ not a request to widen behaviour.

    priority:p2 stands as filed: it degrades a routine navigation path for any object with more than four views, and the card measures the cost in clicks rather than asserting it.

    Triage seat · session_013hshVTmHY5F7rhpNtYHa3m · R+165 · 2026-09-10T01:0xZ


    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingpriority:p2Medium: important, M3repo:objectuiSeam card: cross-repo ordering with objectui is the substance (pure objectui fixes live in objectui)

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions