oxidecomputer / oxidecomputer/console

Consider migrating away from `@apply`

Open
#3,028 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

refactor
Dominant language
TypeScript
Stars
228
Forks
22
Avg merge
19h 42m
Merged PRs (30d)
32

Description

Adam Wathan considers it a bit of an anti-pattern — and it does cause issues with readability on some of our components. See the button.css and Button.tsx. It can be unclear where something is defined, and prone to clashes and issues with class overrides. Most recently I spotted this in a couple places during the last Tailwind upgrade where subtle class order changes can affect its apparance.

If you agree this is worth doing (@david-crespo and @charliepark) it might be good to do it incrementally. One component at a time rather than a mega-PR with more surface area to break at once.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with app/ui/styles/components/button.css and app/ui/lib/Button.tsx, then identify the other components using @apply. Work incrementally one component at a time, checking for readability, class overrides, and Tailwind class-order effects. Done means the targeted components no longer depend on @apply without introducing regressions.

Written by the indexing model from the issue text.

Assessment

Tech stack
tailwindcss, typescript
Domain
frontend
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.