Pułapki konstrukcji warunkowych w React i JSX

Czas potrzebny na przeczytanie:5 minut
Opublikowane:14 lutego 2022

Warunkowe renderowanie w React, w przeciwieństwie do takiego Vue.js może odbywać się za pomocą operatorów logicznych. Takie rozwiązanie to w teorii łatwiejsza do nauczenia składania, z drugiej strony niesie ono za sobą szereg pułapek, na które warto zwracać uwagę.

Strzeż się zera

Bardzo często zdarza nam się korzystać z operatora AND (&&), żeby wyświetlić jakiś kawałek JSX. Załóżmy, że tworzymy komponent odpowiadający za wyświetlanie ceny i ilości danego przedmiotu w koszyku. Ilość jest niezbędna do wyświetlenia całego komponentu, a przez to, że pochodzi z zewnętrznego serwisu może mieć wartość typu number lub być pod postacią undefined:

quantity && <PriceAndQuantity quantity={quantity} />;

Jeśli ilość będzie undefined, to po prostu nie wyświelimy komponentu. A co jeśli jej wartość będzie 0? Spodziewalibyśmy się, że tak jak w przypadku undefined komponent nie zostanie wyrenderowany, w końcu 0 jest falsy, dzieje się jednak inaczej... Do naszego drzewa DOM przecieka faktyczne 0! Ale jak?

Właśnie z powodu tego, że 0 jest wartością falsy, JavaScript przetworzy je i natychmiastowo zwróci. Kilka przykładów wykorzystania &&:

0 && true; // 0
true && 0; // 0
false && true; // false
true && ''; // ''

Dlaczego więc takie false albo undefined nie jest renderowane przez JSX w DOM? Ponieważ 0, w przeciwieństwie do tych wartości, jest w 100% poprawnym React Node, dlatego możemy zrobić <p>ilość sztuk: {quantity}</p> i dostaniemy poprawną wiadomość z ilością produktów.

Bardzo częstym przykładem jest również sprawdzanie długości tablicy i na bazie tego renderowane komponentu:

Źle ❌

items.length && <ItemsList items={items} />;

Jak to naprawić? Mam kilka asów w rękawie:

Dobrze ✅

items.length > 0 && <ItemsList items={items} />;

// lub

!!items.length && <ItemsList items={items} />;

// lub

Boolean(items.length) && <ItemsList items={items} />;

// lub

items.length ? <ItemsList items={items} /> : null;

Pierwszeństwo operatorów

Budujemy dashboard dla naszego serwera Discord, w którym administratorzy i moderatorzy będą mogli zmieniać ustawienia serwera. Każdy użytkownik w naszej aplikacji będzie miał specjalne pole roli, na bazie której będziemy chcieli renderować komponent ustawień serwera:

// prettier-ignore
user.role === 'admin' || user.role === 'moderator' && <ServerSettings />;

Olaf, szukam i szukam tej pułapki, ale w tym kodzie nie ma nic nadzwyczajnego!

Wszystko rozchodzi się o tzw. pierwszeństwo operatorów. Logiczny operator AND (&&) ma pierwszeństwo nad OR (||), dlatego pod spodem nasz kodem będzie wyglądał w ten sposób:

Źle ❌

user.role === 'admin' || (user.role === 'moderator' && <ServerSettings />);

Jak już możesz się domyślić, ten kod skończyłby się istną katastrofą! Gdy nasz użytkownik będzie miał rolę administratora, wyrażenie user.role === 'admin' zamieni się na true a to przy operatorze OR (||) zostanie zwrócone do JSX...

Sposób na poprawienie tego, to odpowiednie dostosowanie nawiasów:

Dobrze ✅

(user.role === 'admin' || user.role === 'moderator') && <ServerSettings />;

Newsletter dla Frontend Developerów 📮

Podobają Ci się moje treści? Dołącz do newslettera żeby być na bieżąco ze światem frontendu, zdobądź dostęp do dodatkowych materiałów i bierz udział w konkursach z nagrodami! 🎁

Subskrybuj

Czytelność

Ternaries i czytelność to często toksyczny związek ❌ To jedna z najczęstszych i najbardziej przebiegłych pułapek!

Wróćmy do dashboardu, dla każdej roli użytkownika chcemy wyświetlać osobny dashboard:

Źle ❌

const Dashboard = ({ user }) => (
  <div>
    <Header />
    {user.role === 'admin' ? (
      <AdminUserDashBoard />
    ) : user.role === 'moderator' ? (
      <ModeratorUserDashBoard />
    ) : user.role === 'normal' ? (
      <NormalUserDashBoard />
    ) : (
      <span>Twoja rola nie jest obecnie wspierana</span>
    )}
    <Footer />
  </div>
);

Ałć! Z każdą dodaną rolą ten kod będzie wyglądał tylko gorzej. Spróbujmy podejścia z klasycznymi ifami:

If, if i if 🤔

type UserRole = 'admin' | 'moderator' | 'normal';

const renderUserDashboard = (role: UserRole) => {
  if (role === 'admin') {
    return <AdminUserDashBoard />;
  }
  if (role === 'moderator') {
    return <ModeratorUserDashBoard />;
  }
  if (role === 'normal') {
    return <NormalUserDashBoard />;
  }

  return <span>Twoja rola nie jest obecnie wspierana</span>;
};

const Dashboard = ({ user }) => (
  <div>
    <Header />
    {renderUserDashboard()}
    <Footer />
  </div>
);

Lepiej lepiej, ale nadal te ify mnie nie przekonują, co powiesz na switcha?

A może tak? 🤔

type UserRole = 'admin' | 'moderator' | 'normal';

const renderUserDashboard = (role: UserRole) => {
  switch (role) {
    case 'admin':
      return <AdminUserDashBoard />;
    case 'moderator':
      <ModeratorUserDashBoard />;
    case 'normal':
      <NormalUserDashBoard />;
    default:
      <span>Twoja rola nie jest obecnie wspierana</span>;
  }
};

const Dashboard = ({ user }) => (
  <div>
    <Header />
    {renderUserDashboard()}
    <Footer />
  </div>
);

Hmm, sam nie wiem, czy mamy coś jeszcze w zanadrzu?

React-If

Jakiś czas temu natrafiłem na dość ciekawą bilbiotekę, react-if zamiast korzystać z ternatires, używa zwykłych komponentów:

const Dashboard = ({ user }) => (
  <div>
    <Header />
    <If condition={user.role === 'admin'}>
      <Then>
        <AdminUserDashBoard />
      </Then>
    </If>
    <If condition={user.role === 'moderator'}>
      <Then>
        <ModeratorUserDashBoard />
      </Then>
    </If>
    <If condition={user.role === 'normal'}>
      <Then>
        <NormalUserDashBoard />
      </Then>
    </If>
    <Unless condition={['admin', 'moderator', 'normal'].includes(user.role)}>
      <span>Twoja rola nie jest obecnie wspierana</span>
    </Unless>
    <Footer />
  </div>
);

Mamy tutaj do dyspozycji takie komponetny jak <If/>, <Else/>, <When/>, <Unless/>, a nawet odpowiednik klasycznego <Switch/>:

A może tak? 🤔

const Dashboard = ({ user }) => (
  <div>
    <Header />
    <Switch>
      <Case condition={user.role === 'admin'}>
        <AdminUserDashBoard />
      </Case>
      <Case condition={user.role === 'moderator'}>
        <ModeratorUserDashBoard />
      </Case>
      <Case condition={user.role === 'normal'}>
        <NormalUserDashBoard />
      </Case>
      <Default>
        <span>Twoja rola nie jest obecnie wspierana</span>
      </Default>
    </Switch>
    <Footer />
  </div>
);

Frontend Developerzy, którzy przyzwyczajeni są do pisania we Vue, czy Angularze znają podobne patterny, ale mi jakoś ciężko się do nich przyzwyczaić, chociaż muszę przyznać, że to o wiele bardziej czytelne :)

Pattern Matching

A co powiesz na Pattern Matching? Halo Olaf, ale przecież ECMA proposal dla tej konstrukcji jest dopiero w pierwszym stage'u! Uwaga, mam godnego zastępce, ts-pattern to bilbioteka do pseudo Pattern Matchingu zbudowana z myślą o TypeScripcie 💙

Czytelniej ✅

type UserRole = 'admin' | 'moderator' | 'normal';

const Dashboard = ({ user }) => (
  <div>
    <Header />
    {match<UserRole>(user.role)
      .with('admin', () => <AdminUserDashBoard />)
      .with('moderator', () => <ModeratorUserDashBoard />)
      .with('normal', () => <NormalUserDashBoard />)
      .otherwise(() => (
        <span>Twoja rola nie jest obecnie wspierana</span>
      ))}
    <Footer />
  </div>
);

Wygląda to naprawdę świetnie i jest type-safe! Taką konstrukcję możemy również wynieść do funkcji renderUserDashboard :) Czego chcieć więcej?

Minusem takiego rozwiązania jest na pewno konieczność instalowania dodatkowej biliboteki, no cóż, coś za coś.

Podsumowanie

It's a trap! Tak można podsumować konstrukcje warunkowe w React i JSX. Uważajcie na siebie i nie dajcie się złapać!

Do usłyszenia!

Pułapki konstrukcji warunkowych w React i JSX

Strzeż się zera

Pierwszeństwo operatorów

Newsletter dla Frontend Developerów 📮

Czytelność

React-If

Pattern Matching

Podsumowanie

Czytaj więcej w React

Elastyczność komponentów w React - kompozycja vs konfiguracja

Remix - konkurencja dla Next.js czy kolejny bezużyteczny framework?

Dołącz do społeczności!

Strzeż się zera

Pierwszeństwo operatorów

Newsletter dla Frontend Developerów 📮

Czytelność

React-If

Pattern Matching

Podsumowanie

Czytaj więcej w React

Elastyczność komponentów w React - kompozycja vs konfiguracja

Remix - konkurencja dla Next.js czy kolejny bezużyteczny framework?

O autorze

Dołącz do społeczności!