Waarom u uw eigen UI Library zou moeten bouwen

Nu er zoveel op het spel staat in de gebruikerservaring, kan het lijken alsof al uw aandacht moet uitgaan naar het perfectioneren van uw digitale eigendommen. Het is immers moeilijk om een geweldige website of app te bouwen als je geen toegang hebt tot een bibliotheek van UI-componenten die in verschillende projecten kunnen worden hergebruikt. De meeste teams zullen iets voorgefabriceerds pakken, bijvoorbeeld: MUI, Chakra, Mantine, Ect. Ik denk dat elk team zelf zou moeten bouwen en dit is waarom:

Toen ik begon met webdevelopment (ongeveer 6 jaar geleden) was de facto standaard Bootstrap, het was eenvoudig, snel te gebruiken, en had een ton aan functies!

Toen de behoeften van de klanten begonnen te veranderen, meer niche ontwerpen, animaties, ... En op een gegeven moment begon ik te worstelen met Bootstrap. Hoewel Bootstrap eenvoudig te gebruiken is, is het aanpassen ervan moeilijker dan je denkt. Bij het maken van CSS is het niet optimaal om iets cruciaals vele malen te herhalen. En de standaard stijlen van Bootstrap moeten overschrijven staat gelijk aan helemaal opnieuw moeten beginnen met je eigen CSS. Weet je dit nog: !important ?

Toen ik met React begon, werden Styled-Components erg populair. Styled-Components is een CSS-in-JS package waarmee je CSS rechtstreeks in je component bestand kunt gebruiken. Het is vrij eenvoudig te leren omdat de syntaxis hetzelfde is als die van CSS.

Beschouw de volgende paragraaf component, die een p element maakt.

const Paragraph = styled.p`
  font-size: 1.2rem;
  color: blue;
`;

U kunt deze component gebruiken zoals elke andere React component.

const Index = () => {
	return (
		<Paragraph>A styled component paragraph</Paragraph>
	)
}

Het is ook ongelooflijk gemakkelijk omdat het werken met toestanden en props eenvoudiger is. De props bepalen bijvoorbeeld de kleur en de achtergrond van deze component.

const Button = styled.button`
  padding: 0.8rem 1.6rem;
  background-color: ${(props) => (props.primary ? "purple" : "white")};
  border: 1px solid #00000;
  color: ${(props) => (props.primary ? "white" : "purple")};
`;
 
export default function Home() {
  return <Button primary>Primary</Button>
}

U hoeft de props niet handmatig aan de CSS toe te voegen wanneer u styled components gebruikt. Omdat het altijd beschikbaar is, wordt het maken van stijlen die afhankelijk zijn van de gegevens van de component eenvoudiger.

De nadelen

Het gebruik van de styled-components bibliotheek heeft veel voordelen, maar ook nadelen.

Onderscheid maken tussen styled-componenten en React-componenten kan moeilijk zijn, vooral buiten een atomic design system. Bijvoorbeeld:

<Main>
  <Nav>
    <ListItem>
      <LinkText>Adopt a Pet</LinkText>
    </ListItem>
    <ListItem>
      <LinkText>Donate</LinkText>
    </ListItem>
  </Nav>
  <Header>Adopt, don't shop!</Header>
  <SecondaryBtn btnText="Donate" />
</Main>

Styled Components worden gecompileerd tijdens runtime

Voor toepassingen die styled components gebruiken, downloadt de browser het CSS en parsed het met JavaScript voordat het in de pagina wordt geïnjecteerd. Dit veroorzaakt performance problemen omdat de gebruiker bij de eerste lading veel JavaScript moet downloaden.

Statische CSS is veel sneller. Het hoeft niet verwerkt te worden voordat de browser het gebruikt om pagina's te stylen. De styled-components bibliotheek wordt echter met elke uitgave beter. Als je je wat verminderde prestaties kunt veroorloven, ga je gang en gebruik het.

Ik was vroeger een grote fan van Chakra, soms helpt het om code echt snel te verplaatsen terwijl het er "oké" uitziet, dit is geweldig voor admin dashboards.

De belangrijkste voordelen

Alle componenten van Chakra UI zijn toegankelijk volgens de WAI-ARIA standaarden. ARIA is een anacroniem voor "Accessible Rich Internet Applications". ARIA, een initiatief dat in 2006 van start is gegaan, is een reeks attributen die we aan HTML kunnen toevoegen om webinhoud toegankelijker te maken voor gebruikers met een handicap die gebruik maken van hulptechnologieën. Met ARIA kunnen schermlezers de bedoelingen van de webpagina explicieter beschrijven aan de gebruiker. Met ARIA-attributen kunnen we de toestand, eigenschappen en functies van elk element op de pagina beschrijven. Hierdoor kunnen gebruikers met een visuele beperking de paginastructuur beter begrijpen, welke elementen interactieve besturingselementen zijn, hoe het toetsenbord op de pagina reageert, dynamische elementen zoals modals en dropdowns, en nog veel meer.

Componenten zijn gemakkelijk te thematiseren in vergelijking met bootstrap bijvoorbeeld.

Door ChakraProvider te gebruiken in de root van je applicatie, rendert chakra automatisch een GlobalStyle component.

// 1. Using a style object
const theme = {
  styles: {
    global: {
      'html, body': {
        color: 'gray.600',
        lineHeight: 'tall',
      },
      a: {
        color: 'teal.500',
      },
    },
  },
}

// 2. Using a function
// NB: Chakra gives you access to `colorMode` and `theme` in `props`
const theme = {
  styles: {
    global: (props) => ({
      'html, body': {
        fontSize: 'sm',
        color: props.colorMode === 'dark' ? 'white' : 'gray.600',
        lineHeight: 'tall',
      },
      a: {
        color: props.colorMode === 'dark' ? 'teal.300' : 'teal.500',
      },
    }),
  },
}

U zult meer doen met minder in minder tijd, wat in feite het doel is van de meeste bibliotheken en frameworks.

De nadelen

Hetzelfde verhaal als bij bootstrap, als het ontwerp eenmaal is veranderd in iets op maat, is het moeilijk om het te stylen. Op dat moment wordt styling een gedoe. Bijvoorbeeld:

De onderstaande code zijn tabs. Het werkt zoals weergegeven, maar volgens de ontwerpen moet de onderste rand tussen de tabbladen schuiven.

const TabView = () => {
	return (
		<Tabs>
		  <TabList>
		    <Tab>One</Tab>
		    <Tab>Two</Tab>
		    <Tab>Three</Tab>
		  </TabList>
		
		  <TabPanels>
		    <TabPanel>
		      <p>one!</p>
		    </TabPanel>
		    <TabPanel>
		      <p>two!</p>
		    </TabPanel>
		    <TabPanel>
		      <p>three!</p>
		    </TabPanel>
		  </TabPanels>
		</Tabs>
	);
}

Maar er is geen mogelijkheid om de onderkant tussen de tabbladen te laten glijden. Het is mogelijk om de ref's van de tab component te gebruiken, maar dat is gewoon een heel gedoe om een simpel css-probleem op te lossen.

Door chakra te gebruiken zal de gebruiker een nieuwe syntax moeten leren (opnieuw, ... ) bv:

Het veranderen van de responsiveness van een div gebeurt zoals hieronder.

<Box width={[300, 400, 500]}>
  I am a div
</Box>
// 300 will be applied from sm (30em)
// 400 will be applied from md (48em)
// 500 will be applied from lg (62em)

Voor nieuwe ontwikkelaars is dit uiterst verwarrend en niet ideaal.

Aangezien Chakra emotion gebruikt onder de motorkap, wordt css opnieuw gegenereerd tijdens runtime. Dit kan leiden tot prestatieproblemen wanneer de applicatie schaalt.

Headless componenten! Headless componenten zijn de componenten die geen gebruikersinterface hebben maar wel functionaliteit. Het maakt niet uit hoe je componenten eruit zien, hoe ze zijn ontworpen, gestyled. Het geeft je enkel de functionaliteit en hoe het eruit zal zien wanneer het mounted of hovered wordt is onder jouw controle. Het scheidt de logica en het gedrag van een component van zijn visuele weergave.

In dit voorbeeld gebruik ik Radix-ui maar React Aria, HeadlessUI, Ect kunnen ook gebruikt worden.

Radix biedt geen Inputs, Buttons, ... dat is omdat die dingen al bestaan in html ze zijn styleable en toegankelijk. Maar wat biedt Radix eigenlijk? Toasts, ProgressBars, Modals, Tooltips, ... maar zonder stijl.

Als het gaat om styling, zullen headless componenten goed werken met elke styling oplossing. Als je van Tailwind CSS houdt, gebruik dan gewoon hun klassen op de markup. Als CSS-in-JS je ding is - je kunt ze gemakkelijk stylen met styled-components, Emotion, vanilla-extract of Stitches. Je hoeft niet het eigen aanpassingsmechanisme van de UI-bibliotheek te gebruiken, die zijn meestal complex en vaak gekoppeld aan de specifieke implementatie van de bibliotheek.

Bijvoorbeeld: Radix-ui Dropdown-menu met TailwindCss.

export default function App() {
  return (
    <div className="App p-10">
      <DropdownMenu.Root>
        <DropdownMenu.Trigger
          className={`bg-indigo-500 text-white py-2 px-8 rounded cursor-default`}
        >
          Trigger
        </DropdownMenu.Trigger>
        <DropdownMenu.Content className={`p-1 shadow-xl rounded`}>
          <DropdownMenu.Item
            className={`py-2 px-8 rounded cursor-default focus:outline-none focus:bg-indigo-400 focus:text-white br-1`}
          >
            Cut
          </DropdownMenu.Item>
          <DropdownMenu.Item
            className={`py-2 px-8 rounded cursor-default focus:outline-none focus:bg-indigo-400 focus:text-white br-1`}
          >
            Copy
          </DropdownMenu.Item>
          <DropdownMenu.Item
            className={`py-2 px-8 rounded cursor-default focus:outline-none focus:bg-indigo-400 focus:text-white br-1`}
          >
            Paste
          </DropdownMenu.Item>
          <DropdownMenu.Arrow className="text-white" fill="currentColor" />
        </DropdownMenu.Content>
      </DropdownMenu.Root>
    </div>
  );
}

Het gebruik van headless componenten voorkomt ook dat de uiteindelijke bundel te groot wordt. Omdat ik alleen de componenten en hooks importeer die ik echt nodig heb, weet ik dat de uiteindelijke bundel alleen het essentiële zal bevatten en niet de extra code die altijd samen met een grote UI-bibliotheek wordt geïnstalleerd.

Sinds ik headless components heb leren kennen en gebruiken, heb ik ontdekt dat ik voor projecten met zeer specifieke ontwerpeisen geen UI-framework nodig heb of wil gebruiken. Mijn developer experience is sterk verbeterd sinds ik headless components ben gaan gebruiken. Een ander voordeel was dat het mij in staat stelde React-componenten effectiever te ontwikkelen door logica en functionaliteit te isoleren van de gebruikersinterface.