No to ja jestem bardziej radykalny. Mały komponent to taki, który robi jedną rzecz i który ciężko podzielić na mniejsze. Czyli zwykle pewnie od jednej do około 40 linijek kodu. Generalnie lubię jak najmniejsze komponenty. Jak widzę komponent, co ma 100-200 linijek kodu, to się zastanawiam czy na pewno musi być taki duży (zwykle nie musi).
Z tą 1 linijką to nieźle pojechałeś. Totalna skrajność. Komponent jednolinijkowy da się uzyskać jedynie przez użycie tak zwięzłej konstrukcji jak:
export default () => <div>Hello World!</div>;
Tylko co takie coś wnosi? A co ze stylami (które u mnie np. pisze się w JS-ie)? To już nie jest część komponentu? A co jeśli masz kontener Relaya? To nadal jest w jednym pliku i jest to niemalże integralna część komponentu i powinien ten kod leżeć w tym samym miejscu. I gdzie wtedy ta 1 linijka? Ba, nawet w 40 tego pewnie nie zmieścisz. Pomijam już smart komponenty, gdzie dochodzi obsługa zdarzeń chociażby.
Nie wszystkie komponenty mogą być tzw. commonsami (np. Avatar) i mieścić się w kilku, może kilkunastu linijkach. Po zbudowaniu odpowiedniej codebase z takich komponentów tworzysz inne (kompozycja) i wtedy nie ma szans, żeby uzyskać tak skrajne wyniki. Bycie radykalnym jest złe.
Może to się im sprawdza na produkcji, ale jako developer nie chciałbym musieć ogarniać 20 tysięcy komponentów, bo ogarnięcie takiej bazy kodu byłoby raczej trudne (chociaż Dan Abramov na Twitterze pisał, że mają jakąś przeglądarkę komponentów).
Storybook, Atellier chociażby? Poza tym odpowiednia modularyzacja i nikt nie każe skakać Ci między 20 tysiącami komponentów. Zdajesz sobie sprawę, że w dużych teamach są różne odpowiedzialności i prawdopodobnie nie ma jednej osoby, która przejrzała cały codebase złożony z tych 20 tysięcy komponentów?
Poza tym sama liczba nic nie mówi - nie wiadomo, czy potrzebują tyle komponentów. Chyba nigdy nie mówili dokładnych powodów, dla których mają tyle komponentów, nie napisali żadnego case study na ten temat. Więc kierowanie się tym to może być trochę jak wybieranie PHP dlatego, że Facebook napisany jest w PHP.
No tak, zdecydowali się na taki zabieg ot tak. ;) Podobnie z przypadku powstał GraphQL, Relay - do tej pory większość ludzi uważa to za przerost formy nad treścią. Informacja, którą przytoczyłem jest do wygooglowania na blogu Reacta chociażby, intencja o podziale komponentów na aż tak małe była tłumaczona na konferencjach (też tej oficjalnej w siedzibie FB). Odsyłam chociażby do prezentacji z cyklu o Relayu, gdzie podział na małe komponenty sprzyja w konsekwencji zmniejszenia właśnie tego całego overhead, a nie odwrotnie jak sugerujesz. Co więcej, większe komponenty komplikują w konsekwencji reprezentację modelu danych na ich poziomie (z udziałem Relaya zwykle sprowadzasz wszystko do płaskich jsonów i nie zastanawiasz się nad tym jak pod spodem klejone są zapytania - tak btw).
Tylko, że wg mnie problem jest z czym innym trochę - to nie jest kwestia dużo małych vs. mało dużych komponentów, ale o to, czy interfejsy mają być proste czy skomplikowane, czy architektura (nie tylko komponenty, ale cała architektura projektu) jest prosta czy skomplikowana.
Prostota interfejsów w dużej mierze zależy od tego, jak zostanie juz zaprojektowany z punktu widzenia designu. Ja pracuję na styku designu na szczęście, ale znam ludzi, którzy z designerami nie mają kontaktu tylko dostają gotowce, gdzie często interfejs jest przekombinowany. Dobrych designerów jest dużo mniej niż dobrych developerów niestety. A pamiętaj, że są też aplikacje, branże, gdzie problem i nomenklatura są na tyle skomplikowane, że interfejs nie będzie prosty. W dodatku zdarzyło mi się też pracować przy apce, która miała nieintuicyjny interfejs z punktu widzenia przeciętnego usera, ale była skierowana do specjalistów, którzy mieli już swoje przyzwyczajenia (nierzadko absurdalne, ale cóż poradzić) i w oparciu o nie powstał UI, nie w oparciu o best practice'y z goodui.org czy czegoś podobnego.
To z czym mam problem to nie małe komponenty (bo je lubię), tylko raczej hierarchiczna ich struktura
No to przychylam się do argumentu, że prawdopodobnie widok został źle zaprojektowany, albo nie da się tego już uprościć. ;) Niekoniecznie ma to związek z kodem aplikacji.
- dużo komponentów - większy ból dla programisty, żeby to ogarnąć wszystko, dużo plików, nie wiadomo co jest od czego zależne w jaki sposób, co się w sobie zawiera (chyba, że firmy korzystają z jakichś sensownych styleguidów).
Wydawało mi się, że styleguide'y odnośnie kodowania (JS, React, może CSS, plus baza komponentów ala lokalny bootstrap) i designu (coś w stylu goodui + baza komponentów w invision) to standard. Cóż, w takim razie powinien być to standard w większych aplikacjach, bo potem tworzą się kwiatki jak w Spotify (polecam poczytać case study odnośnie tworzenia styleguide'a i problemów jakie do tego doprowadziły).
Ale i tak - jeśli tego jest za dużo, to nawet jak będziesz miał narysowany graf zależności, to może być to cięzko ogarnąć.
I tu znów kwestia modularyzacji i odpowiedzialności. Wiem, że to trudny problem, ale teamy sobie z tym radzą. Serio.
- cięzko zapanować na przepływem danych, generuje to albo potrzebę przekazywania danych jawnie przez propsy albo jakąś magię w stylu kontekst czy
connect
z Reduxa albo przez samodzielne odpytywanie store'ów/innych źródeł danych przez komponenty (tyle, że im więcej magii, tym cięzej zapanować nad wszystkim).
Dlaczego connect to dla Ciebie magia? Tego nie rozumiem. W żadnej aplikacji nie musiałem jeszcze użyć kontekstu, ani refsów (o tym nie wspomniałeś, ale to też jest efektem często tego problemu :P). Jako inspiracje polecam materiały od Netflixa, kolesie sobie bardzo dobrze radzą z ujarzmieniem przepływu danych w bardzo skrajnych warunkach (i nie mówię o środowisku telewizorów).
Co do shouldComponentUpdate to pamiętaj o Immutable chociażby, poza tym Redux nie jest do wszystkiego. Jeśli potrzebujesz częstych aktualizacji złożonych struktur komponentów to wybierz narzędzie do tego stworzone, np. MobX. Flux to nie jest holy grail i ma też swoje słabsze strony (albo inaczej - miejsca, w których na niewiele się zdaje z punktu widzenia perf).
Co do reszty, której nie skomentowałem to ogółem się zgadzam i rozumiem ból. Ba, na co dzień każdy doświadcza podobnych problemów, ale nie są to rzeczy, nad którymi nie da się zapanować. A jako ciekawostkę odnośnie upraszczania tworzenia UI może warto poczytać o Elmie. ;)