shadcn.io is not affiliated with official shadcn/ui
Settings Page Skeleton Block for Solid
A settings page whose tabs reload: pressing Profile, Notifications or Security swaps the three groups of controls from bars to a working Input, Switch or Select, at one fixed height.
Installation
Overview
Show a settings page while a section loads, then swap its controls in without moving anything, with this settings page skeleton for Solid with Ark UI. A hairline frame with a plus mark on each corner holds a line Tabs list (Profile, Notifications, Security) over three groups of controls from Smalti, a newsletter platform, and a Save button. The tabs, each group's label and description and the button are real from the first paint; the three controls of the open tab are Skeleton bars that become a working Input, Switch or Native Select in the same place. Pressing a tab is a reload: the open tab's controls go back to bars and come in again. Save is the panel's one Shine Button, unavailable until the controls are in, then says nothing was saved. The tab list scrolls on a phone. It's built from Skeleton, Tabs, Input, Switch, Native Select, Shine Button and Guides, with a CSS entrance only. For account settings, preferences and any form that loads per section.
FAQ
What stays local, and how do I wire it to a real query?
Nothing is fetched. The settings are typed in ProfilePanel, NotificationsPanel and SecurityPanel, Load starts a 700 millisecond timer, and when it ends the phase becomes ready and the data swaps in; Reload goes back to the bars and in again. To wire it for real, delete the timer, the Load button and the polite line, and set data-state (loading or ready) and aria-busy on the region from your query's pending state, or use the bars as a Suspense fallback and render the real content when it arrives. Each panel holds its values in state, so you can type and flip them, but Save only sets a note; in your app, send the values, then set them from the response and show a Problem line if it fails. Keep one component for the bars and the data so they can't drift apart.
Why does pressing a tab reload?
The tab is the surface's own source of data: a different section means a different request. Pressing it restarts the 700 millisecond timer and puts the open panel back to bars, and a Reload goes back to the saved values. Only the open tab's panel is on the page, so ids and labels never repeat.
How is the height held between tabs?
The three sections have different controls, so an unseen copy of all three sits in the open panel's grid cell, hidden from sight, assistive technology and the keyboard. The tallest sets the box. A TabsContent carries flex-none rather than flex, which would override its hidden state.
Why doesn't the page jump when the controls arrive?
Every control shares a grid cell with its bar, the rows have a minimum height and the label and description are real in both phases. The polite line reserves two lines, so the panel is exactly as tall before, during and after loading.
Is it accessible?
The region is marked busy while it loads and carries a screen-reader-only "Loading settings…", and the polite line announces what loaded once. The bars are hidden from assistive technology and the layer that isn't showing is invisible, so it is neither read nor focusable. The tab list is a real tab list with arrow-key movement, each control is named by its visible label, and Save is aria-disabled rather than hidden while loading. The pulse stops when the data is in, and under reduced motion there is no pulse, no spinner and no stagger: the swap is instant.