Kontenery w React.js

Tudzież containers z docelowego języka. Z założenia bardzo przydatne. W praktyce prowadzące do pewnych patologicznych zachowań w projekcie. W efekcie powodując zamieszanie i utrudniają rozwój aplikacji.

Podział na smart i dump komponenty w React jest znany od wczesnych dni biblioteki. Inną parą określeń, być może bardziej profesjonalną, jest podział na kontenery i komponenty. Tych ostatnich, głównym celem jest głównie wyświetlanie komponentu, bez niepotrzebnej logiki. Kontenerów celem jest połączenie komponentów z odpowiednią logiką i źródłem danych.

Co nam to daje? Przede wszystkim reużywalność. Wyobraźmy sobie komponent listy zasilany różnymi danymi. Dla przykładu tablicą użytkowników lub tablicą kategorii. Idea ta jest dość piękna. Natomiast trzeba uważać na pewne pułapki.

Komponenty z natury są zrobione tak aby były reużywalne. Po to właśnie są argumenty wejściowe aby nimi sterować w zależności od potrzeb. Takie komponenty, które są używane w więcej niż jednym miejscu powinny wylądować zazwyczaj w katalogu components. Natomiast na jakim poziomie on się znajduje powinno decydować jak bardzo popularny jest dany komponent. Inny zasięg będzie miał typowy przycisk a inny wyszukiwarka kategorii.

W przypadku kontenerów częstym problem jest wymuszenie katalogu containers. Jest to dział ze względu na typ komponentu, nie ze względu na funkcjonalność. Analogicznym podziałem w projekcie Redux jest na katalogi actions i reducers. Nie stosujmy na siłę takiego podziału. Na siłę w ten sposób do każdej komponentu musimy utworzyć kontener i komponent. W takim przypadku trudno określić czy dany stan powinien być bardziej po stronie kontenera czy komponentu.

Jak można zrobić to lepiej?

Przede wszystkim projektując daną strukturę katalogów pamiętajmy o naszych potrzebach. Każda podstrona, sekcja, powinna zacząć się od utworzenia komponentu. O ile może mieć on miano kontenera nie musimy na siłę stosować podkatalogu ani sufixu. Jeśli zajdzie potrzeba dzielenia kodu komponentu pomiędzy kilkoma innymi komponentami. Dopiero wtedy utwórzmy katalog components na wspólne komponenty.

Wierzę, że taka struktura jest o wiele czytelniejsza i wygodniejsza. Bowiem wymaga również mniej pracy przy przesyłaniu danych pomiędzy większą ilością komponentów.

Inny podział komponentów

W ten sposób można na usta ciśnie się inny podział. Moim zdaniem bardziej odpowiadający potrzebom typowej aplikacji. Komponenty dedykowane i reużywalne.

Dedykowane są dla danych podstron/sekcji. Użyte zazwyczaj tylko raz w aplikacji.

Reużywalne, jak łatwo się domyślić, używane wiele razy, pomiędzy innymi komponentami wyższego rzędu.