Konwencja nazewnictwa w Styled Components – 3 sposoby

Link do artykułu "Jak nazywać styled-componenty"

Jak nazywać styled componenty? W artykule przedstawiam propozycje konwencji nazewnictwa.

Problem z nazewnictwem

Podczas tworzenia stylowanych komponentów (styled components) zacząłem zastanawiać się jak powinienem je nazywać. Styled component nie może mieć takiej samej nazwy jak komponent, który będzie stylowany.

Można pokazać to na przykładzie prostego komponentu – Buttona.

// ./styled/Button.js
import styled from 'styled-components';

export const Button = styled.button`
  // styles
`;

// ./Button.js
import React from 'react';
import {Button} from './styled/Button';

export default function Button() {
  
  return (
    <Button></Button>
  );
}

// Nazwy takie same, tak nie może być :(

Tak nie może być. Zatem jak nazwać, żeby było dobrze?

Zacząłem szukać rozwiązań tego problemu i dotarłem do kilku ciekawych dyskusji oraz artykułów. Poniżej przedstawiam kilka propozycji, a na końcu opiszę własny wniosek.

Propozycje konwencji nazewnictwa dla Styled Components

Sposób 1: Stosowanie przedrostków

Stosowanie przedrostków wydaje się być najłatwiejszym sposobem na nazywanie komponentów. Przedrostkiem może być Styled, S, Sc lub inna nazwa.

Przykład z Buttonem wyglądałby w następujący sposób.

// ./styled/StyledButton.js
import styled from 'styled-components';

export const StyledButton = styled.button`
  // styles
`;

// ./Button.js
import React from 'react';
import {StyledButton} from './styled/StyledButton';

export default function Button() {
  
  return (
    <StyledButton></StyledButton>
  );
}

Plusy

  • Łatwo rozróżnić styled component od standardowego komponentu – wiadomo czy komponent posiada w sobie logikę czy tylko same style
  • Nie będzie konfliktu pomiędzy nazwą styled componentu oraz docelowym komponentem
  • Bardzo łatwo wprowadzić takie rozwiązanie

Minusy

  • Każdy styled component posiada w sobie przedrostek – może się okazać, że niekoniecznie komplikowany jest projekt przez dodawanie kolejnej abstrakcji
  • Trzymanie wszystkich komponentów w folderze styled czy styles wydaje się nadprogramowe, ponieważ duplikujemy nazwy w folderze i komponencie (./styled/StyledButton.js)

Sposób 2: Importowanie wszystkich styled components

Kolejnym sposobem jest importowanie wszystkich styled componentów z wykorzystaniem import * as NAZWA.

// ./styled/Button.js
import styled from 'styled-components';

export const Button = styled.button`
  // styles
`;

// ./Button.js
import React from 'react';
import * as S from './styled';

export default function Button() {
  
  return (
    <S.Button></S.Button>
  );
}

Plusy

  • Łatwa implementacja
  • Nie komplikujemy projektu poprzez sztuczne nazewnictwo tak jak w przypadku dodawania przedrostków

Minusy

  • Problemy z tree shaking – lintery nie pomogą w odszukaniu nieużywanych importów
  • W przypadku tworzenia styli wewnątrz komponentu należy utworzyć obiekt const S = {} i do niego przypisać styled componenty, aby była możliwość skorzystania z tej samej konwencji

Sposób 3: Unikalna nazwa

Ten sposób wydaje się być najbardziej naturalnym. Polega on na nadawaniu unikalnej nazwy dla każdego styled componentu.

// ./styled/ButtonWrapper.js
import styled from 'styled-components';

export const ButtonWrapper = styled.button`
  // styles
`;

// ./Button.js
import React from 'react';
import {ButtonWrapper} from './styled/ButtonWrapper';

export default function Button() {
  
  return (
    <ButtonWrapper></ButtonWrapper>
  );
}

Plusy

  • Łatwość w implementacji, sposób wydaje się być najbardziej naturalny
  • Nie będzie konfliktu pomiędzy nazwą styled componentu oraz docelowym komponentem

Minusy

  • Czasami tworzenie nazw może być problematyczne, Wrapper będzie często w nazwach (a może to i lepiej?)
  • Ciężko odróżnić styled componenty od zwykłych komponentów (jedynie można to zrobić poprzez nazwę folderu styled w imporcie lub poprawną nazwę – wtedy ten punkt może okazać się nieistotny)

Wniosek. Jak nazywać styled componenty?

Najbardziej przekonuje mnie sposób trzeci, ponieważ wydaje mi się najbardziej logiczny i przejrzysty. Oczywiście trzeba zwrócić uwagę na to jak są nazywane komponenty. Jednak po krótkim czasie bardzo łatwo przyzwyczaić się do tego sposobu.

Ciekawym rozwiązaniem wydaje się być sposób drugi. Jednak przez problem z tree shakingiem może okazać się nieakceptowalny.

Źródła / linki

Poniżej podrzucam kilka linków do dyskusji i artykułów.

https://github.com/styled-components/styled-components/issues/1604

https://medium.com/inturn-eng/naming-styled-components-d7097950a245

https://www.npmjs.com/package/styled-as-components

https://tech.decisiv.com/structuring-our-styled-components-part-i-2bf21fa64b28

https://zzzzbov.com/blag/styled-components-naming-convention


Czy znasz inny sposób nazewnictwa? A może korzystasz, z któregoś powyżej? Podziel się tym w komentarzu.

5 thoughts on “Konwencja nazewnictwa w Styled Components – 3 sposoby

  1. Można jeszcze tak 😉

    —————————————————
    import styled from ‚styled-components’;
    import React from ‚react’;

    export function Button({ className, children, as : As = „button”, …rest }) {
    return (
    {children}
    );
    }

    export default styled(Button)`
    // styles
    `
    —————————————————

    To nam daje pełną elastyczność w jednym pliku:

    1. style są razem z komponentem
    2. defult export = ostylowany, named export = bez styli (dowolość)

    Bonusowo:
    3. As = pozwala na modyfikację elementu HTML (czasami chcemy link żeby wyglądał jak button) wtedy użycie byłoby następujące:

    Jestem linkiem który wygląda jak button 🙂

    1. Dzięki za pomysł!
      Zastanawiam się jak przetestować tylko style w takim wariancie. No i czy fakt, że to jest w jednym pliku to nie minus w przypadku bardziej rozbudowanych komponentów.

        1. Standardowo styled-componenty testuję poprzez snapshoty (jest-styled-components). Szczególnie przydatne jeśli w projekcie znajduje się theme. Widać każdą zmianę styli dla każdego komponentu, natomiast jeśli wszystko znajduje się w jednym pliku snapshot traci sens, ponieważ każda zmiana w komponencie wpływa na ten snapshot (a chcemy mieć osobny wynik dla styli).

          W tym artykule jest przykład:
          https://medium.com/styled-components/effective-testing-for-styled-components-67982eb7d42b

  2. Dopiero poznaje stylowanie w reakcie, bardzo wiele osób namawiało mnie do tego. Na razie początki są trudniejsze z rozumieniem wszystkiego – ale całkiem fajne podejście, coś nowego :)) nie wiem czy zostanę na zawsze przy tym ale obecnie będę musiał się przestawić.

Pozostaw odpowiedź PrzemuH Anuluj pisanie odpowiedzi

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *