mirror of
https://github.com/luxfi/explore.git
synced 2026-09-24 00:28:18 +00:00
Filter rendered twice on /tokens and dropped into the search input. Both
blocks in TokensActionBar are meant to exist — one for mobile with the sort
control, one for desktop inside the sticky ActionBar — and the Chakra port
turned each HStack into a bare div, losing display={{base,lg}} and gap. With
no breakpoint both drew at once, and with no flex the button, the sort and
the input stacked instead of sitting in a row. Every sibling action bar
(VerifiedContracts, NameDomains, Clusters) kept `flex lg:hidden` /
`hidden lg:flex`; tokens is the one file where the port dropped them, so this
restores that pattern rather than inventing a second one. Desktop now
measures one filter at x=32 w=92 and one input at x=136, no overlap.
The clipped label is a different fault underneath it. @luxfi/ui's ButtonFrame
sets inline-flex, alignItems, gap, a fixed height and overflow:hidden but
never flexDirection, and it is built on a react-native View, which lays out
in a column — so icon and label stacked and the fixed height cut the label
off. Swept 39 buttons over nine pages at both viewports: only three carry
more than one child and only Filter clips, so this says row at FilterButton,
the one component every filter in the app goes through. Inline because the
frame's own class outranks a utility. The primitive is still wrong and wants
fixing upstream.
The footer's social row was never a colour problem. Its branch of Footer
leaves the three left-hand blocks unwrapped, so a two-column grid takes them
as three children and the links land in the 470px track instead of the wide
one; five 160px columns do not fit there, the two mobile 1fr columns were
still the only explicit tracks at lg, and they collapsed to zero width with
Contribute, X (Twitter) and Discord painting on top of each other. Wrapping
the left column the way the custom-links branch already does, and dropping
the mobile tracks at lg, spreads them 576 to 1392 with nothing overlapping at
1440, 1024 or 390.
Addresses render check-summed again. The comment said the API always answers
in EIP-55; it case-folds now, deliberately, so a checksummed URL resolves
instead of 404ing, and `data.hash ?? getCheckedSummedAddress(hash)` took the
lower-case payload every time the address existed. Checksum whatever is
displayed instead — getAddress reads any case and is idempotent, so one call
covers a hash from the API, from the route, or from neither yet. Display
only; the backend keeps folding.
Co-authored-by: Hanzo Dev <[email protected]>