React - raczej o konwencjach

1

Cześć,
Mam zagwozdkę natury raczej formalnej. W apce tworzę dużą liczbę komponentów React, przy czym niektóre z nich są bardzo 'małe'. Tak, w tym momencie brakuje mi dobrego słowa, na objęcie komponentów renderujących powiedzmy jednego mały nagłówek, ewentualnie nierenderujących samodzielnie treści (a tylko po ujęciu w innym komponencie) który sposób wyświetlania treści modyfikuje. Z drugiej strony są to podstawowe cegiełki wykorzystywane przez duże komponenty. Granica czasami jest intuicyjna i nieostra, fakt. Natomiast pytanie brzmi czy takie maleństwa powinny być zasadniczo zgrupowane:

w osobnym folderze o nazwie dajmy na to details
w osobnym pliku o nazwie np. details
w jakikolwiek inny sposób zebrane i pogrupowane

oraz, czy wskazane jest nadawanie im jakichś 'znaczących' nazw SpinnerDetail.

Szukałam sugestii tutaj:
https://github.com/airbnb/javascript/tree/master/react#naming

Ale nic tam takiego nie ma

Ewentualnie, jeżeli nie ma konwencji, jakie podejście polecacie?
I jeszcze jedno. Mamy Reduxa, tworzymy coś przez Connect

const TableBody = connect(mapStateToProps, null)(_TableBody)

O ile literał TableBody jest chyba OK to czy _TableBody dla nazwania funkcji niepołączonej też jest OK?

5

Osobiście preferuje podział na komponenty:

  • generczne reużywalne pomiędzy różnymi niezależnymi komponentami, trzymane w w /src/components/nazwa_komponentu/
  • specyficzne dla konkretnej strony, trzymane w /src/pages/nazwa_strony/nazwa komponentu/

jeśli danych komponent jest używany tylko w kontekście innego komponentu to kolejny podfolder dla niego tworze.
I każdy komponent ma zwykle swój folder, bo oprócz tego zwykle dochodzą powiązane z nim dwa pliki: plik testów, i plik storybooka, a często też oddzielny plik styli dla komponentu czy chociażby jeszcze reducer.

Storybook obowiązkowo dla wszystkich komponentów generycznych, i korzeni komponentów specyficznych, podkomponenty mogą mieć storybooka ale nie muszą.

screenshot-20200729120901.png

I jak najbardziej wszystko musi mieć znaczące nazwy, jeśli nie jesteś w stanie wymyślić znaczącej nazwy może to oznaczać że albo komponent robi za dużo albo za mało.

0
neves napisał(a):

Osobiście preferuje podział na komponenty:

  • generczne reużywalne pomiędzy różnymi niezależnymi komponentami, trzymane w w /src/components/nazwa_komponentu/
  • specyficzne dla konkretnej strony, trzymane w /src/pages/nazwa_strony/nazwa komponentu/

jeśli danych komponent jest używany tylko w kontekście innego komponentu to kolejny podfolder dla niego tworze.
I każdy komponent ma zwykle swój folder, bo oprócz tego zwykle dochodzą powiązane z nim dwa pliki: plik testów, i plik storybooka, a często też oddzielny plik styli dla komponentu czy chociażby jeszcze reducer.

Storybook obowiązkowo dla wszystkich komponentów generycznych, i korzeni komponentów specyficznych, podkomponenty mogą mieć storybooka ale nie muszą.

screenshot-20200729120901.png

I jak najbardziej wszystko musi mieć znaczące nazwy, jeśli nie jesteś w stanie wymyślić znaczącej nazwy może to oznaczać że albo komponent robi za dużo albo za mało.

Dzięki. To mi całkiem sporo wyjaśnia, zwłaszcza podejście do nazwy. W tej chwili w komponencie w jednym pliku mam funkcje np. unconnectedSort i Sort - pierwsza jest funkcją jako taką a druga efektem potraktowania jej reduksową funkcją connect. Przedtem ta poczatkowa miała nazwę _Sort ale wyczytałam, że to zarezerwowane dla Lodasha raczej. Właściwie jedną rzecz mam zupełnie inaczej -style, są całkowicie osobno.

0

Jako, że zamiast używać CRA stawiam Reacta na NX'sie to już na start jest rozdzielenie na aplikację, np: /web-main i /libs. W libs trzymam wszystkie rzeczy wielokrotnego użytku jak np redux, czy jakieś uniwersalne komponenty. Folder aplikacji jest u mnie odpowiednikiem /pages. Wewnątrz mam main.tsx do głównych konfiguracj, dalej auth.tsx do oidc i app.tsx, w którym obsługuję routing. Pojedyncze strony trzymam w oddzielnych katalogach i jak mam np listę projektów to mam /projects-list i w środku komponenty powiązane, często też w oddzielnych katalogach. Jeśli robię sobie formularz składający się z kilku kroków staram się opierać na tym https://github.com/eduwebpl/k[...]onents/MultiStep/MultiStep.js. Wygodne w utrzymaniu jak do tej pory doświadczyłem.
Przykład drzewa plików:
apps
-> web-main
--> projects-list
---> projects-list.tsx
---> list
----> list.tsx
----> list.view.tsx
----> list.story.tsx
-> libs
--> redux
---> index.ts
---> lib
----> index.ts
----> store.ts
----> reducers.ts
----> epics.ts
----> types.ts
----> generic
-----> actions.ts
-----> epic.ts
-----> reducer.ts
-----> types.ts
-----> index.ts
----> projects
-----> actions.ts
-----> epic.ts
-----> reducer.ts
-----> types.ts
-----> index.ts

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0