Skip to content

feat(design): the portal drawn from the design, and the Appearance tab - #919

Draft
mortondev wants to merge 13 commits into
feat/builder-2-serverfrom
feat/builder-3-portal
Draft

mortondev wants to merge 13 commits into
feat/builder-2-serverfrom
feat/builder-3-portal

Conversation

@mortondev

Copy link
Copy Markdown
Member

Part 3 of 6 of the portal builder stack. Review and merge in order.

Portal pages, the header, top band, Home blocks, post cards, Roadmap,
Changelog, Help Center, Support and Status read their look from the
published design. Appearance shows the design and opens the builder.
Portal words follow posts on boards, with one word for each language.

Each part typechecks, lints and passes its own tests on top of the part below it. Together the six parts are the builder branch with main merged in.

Portal pages, the header, top band, Home blocks, post cards, Roadmap,
Changelog, Help Center, Support and Status read their look from the
published design. Appearance shows the design and opens the builder.
Portal words follow posts on boards, with one word for each language.
The feedback and help center routes imported loader and head helpers
from the page modules (portalDataParams, landingCopy) and the portal
index imported the feedback route file, so the bundler put the whole
feed, help center search, Ask AI and markdown stack in the entry chunk.
Those helpers now live in small modules of their own and the index loads
the feed page lazily. The widget's eager payload is back to 392 KB gz.
Every card, menu item and header carried its design variants as long
arbitrary Tailwind classes (tag tints, the card rows a design can turn off,
the header on the band, the menu's active looks and fade), and the logo's SVG
filters were drawn on every page. That added 4-17 KB to each portal document.
The variants are now named utilities in globals.css, which cascade as the
arbitrary ones did; the logo filters draw only beside a logo image; the tag
tint lives with the status markers; and the Customise button, which only team
members see, loads on demand.
After removing the leaks (builder modules and design variant classes on
every portal page), what remains is the builder's own footprint:
- The entry chunk is about 10 KB larger: the design route, its search
  schemas, the font loader and the zod features they use. Admin pages
  carry it, so their jsKB ceilings rise by about that.
- Portal pages draw the design's band, page titles, page choices and menu,
  each imported by the portal layout and by pages, so each is its own
  small chunk: 1 to 16 more requests per portal journey.
- The roadmap's cards have vote buttons now (more renders, and the board
  capabilities query), and the vote button is shared with the post page,
  so post journeys gain a request.
- The post page's HTML carries the parts the builder picks by and the
  Powered by footer (40 KB, was 38.6 KB on main).

Only the ceilings a journey exceeded are raised, each to its measured
value; the local bench reads the same as CI on main's build.
The portal now says posts, so the typing journeys timed out looking for a
textbox named Feedback title.

This branch has not been deployed

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant