Nadmiarowy kontekst w nazewnictwie komponentów

Cześć
Mam dwa pytania odnośnie nazewnictwa w React

1. Mamy dwa foldery, niech się nazywają Dogs/ i Cucumbers/.

   W każdym z nich są pliki, w tym pliki z komponentem tabeli. I od razu napiszę że te tabele są na tyle różne, że nie ma sensu kombinowanie w kierunku zrobienia jednej uniwersalnej z długą listą propsów. Nie ma też mowy o importowaniu ich poza pliki danego folderu/ nie mają szansy się spotkac w jednym komponencie.

   Pytanie, czy tabele powinny się nazywać po prostu "Table" czy raczej "DogsTable" i "CucumberTable" ? Czy w drugim przypadkiem nie jest to nadmiarowy kontekst?

2. Czy właściwe są nazwy typu usersOrderedList, paymentsSection (wskazujące na strukturę zawartości/najbardziej zewnętrzny HTML) czy raczej users i payments?

Ja bym zrobił Dogs.

Mam dwa przemyślenia na ten temat.

Po pierwsze, dla mnie istotna jest treść tego komponentu - co one sobą reprezentują, więc najważniejsze że pokazują "dogs" oraz "cucumbers", a to czy je pokazują w tabelce, w drzewie, w liście czy w jakiejkolwiek innej formie, to moim zdaniem jest szczegół. To czy to jest tabelka czy lista, moim zdaniem nie jest istotą tych komponentów. Więc ja bym zostawił "Dogs".

Po drugie, nazywanie komponentów z nazwą elementu html zalatuje trochę notacją węgierską, żeby w nazwie umieścić typ. Kiedyś się robiło zmienne np var integerAge albo var stringName, kiedy systemy typów nie były jeszcze dobrze ogarnięte. Nazywanie czegoś usersOrderedList trochę też tym zalatuje. Plus, jest mało praktyczne, bo jak zmienisz <ol> na <ul>, to co wtedy? Zrobisz rename?

Ok, nie wiedziałem, że coś takiego jak notacja węgierska istnieje. A już na pewno nie wiedziałem, że jest passe. W takim razie do skrócenia, dzięki.

Tak z doświadczenia wiem że posiadanie komponentów o identycznej nazwie to późniejsza strata czasu dla developera. Wyszukiwanie po projekcie nie działa bo masz 15 Table która każda robi coś innego. Jak czytasz kod to masz wtf wszędzie gdzie jest Table.

mamrzeczy.pl napisał(a):

Tak z doświadczenia wiem że posiadanie komponentów o identycznej nazwie to późniejsza strata czasu dla developera. Wyszukiwanie po projekcie nie działa bo masz 15 Table która każda robi coś innego. Jak czytasz kod to masz wtf wszędzie gdzie jest Table.

Niby tak, ale z drugiej strony dokładnie po to masz przestrzenie nazw.

Moim zdaniem łatwiejsze jest bazowanie na nazwie niż przestrzeń+nazwa. Miałem taki projekt gdzie dev zrobił komponent "Component" 50 razy i to była katorga. Ale jak ktoś czuje inaczej to nie ma problemu.

mamrzeczy.pl napisał(a):

Moim zdaniem łatwiejsze jest bazowanie na nazwie niż przestrzeń+nazwa. Miałem taki projekt gdzie dev zrobił komponent "Component" 50 razy i to była katorga. Ale jak ktoś czuje inaczej to nie ma problemu.

Trzeba znaleźć balans.

Jak ktoś ma 50x słowo które jest genetyczne, jak Component mimo przestrzeni nazw, to będzie się tego źle używało i projekt będzie trudno utrzymywał. Poza tym sugeruje ze te klasy mają coś wspólnego ze sobą i powinny być wydzielone?

Ale jeśli masz dwa moduły, które przypadkiem mają klasy które nazywają się tak samo (np. Klasa List w widoku jako lista elementów, i List w domenie jako kolekcja) to właśnie po to są przestrzenie nazw żeby móc ich użyć razem, bo obie są dobre.

ja mam problem, bo robię w Rust silnik gier i robię wektory (takie matematyczne) i chcę rozróżnić:

• 2D vs. 3D
• int vs. float

więc póki co mam struktury:
IntVector2D
FloatVector2D
oraz funkcje pomocnicze
vec2i - zwraca IntVector2D
vec2 - zwraca FloatVector2D

potencjalnie (jak dorobię 3D) jeszcze mógłbym mieć oprócz wyżej wymienionych:
FloatVector3D
IntVector3D
i funkcje
vec3i
vec3

No i więc... zastanawiam się, żeby:

• zrezygnować z intów i używać tylko floatów nawet w sytuacji, kiedy potrzebuję intów, tj. kiedy jedyną prawidłową wartością będą inty (np. wyobraźcie sobie grę w szachy).
• zrezygnować z wektorów 2D i oprzeć wszystko o wektory 3 wymiarowe (albo 4 wymiarowe: xyzw). Dzięki temu nie musiałbym osobnych funkcji do 2D robić, wystarczy, że użyłbym wektora 3D i zignorował wartości z i w (koszt - trochę więcej pamięci potrzebnej do zapisu takich wektorów).

Tylko o ile pomysł trzymania wszystkiego jako 4 wymiarowe wektory (nawet jeśli będą to pozycje 2D) wydaje mi się spoko, to jednak nie jestem przekonany co do rezygnacji z intów. Straciłbym część poprawności płynącej z silnego typowania, plus musiałbym konwertować to i tak do intów (chociaż teraz i tak muszę konwertować inty do floatów w pewnych miejscach).

Co o tym sądzicie?

LukeJL napisał(a):

ja mam problem, bo robię w Rust silnik gier i robię wektory (takie matematyczne) i chcę rozróżnić:

• 2D vs. 3D
• int vs. float

więc póki co mam struktury:
IntVector2D
FloatVector2D
oraz funkcje pomocnicze
vec2i - zwraca IntVector2D
vec2 - zwraca FloatVector2D

potencjalnie (jak dorobię 3D) jeszcze mógłbym mieć oprócz wyżej wymienionych:
FloatVector3D
IntVector3D
i funkcje
vec3i
vec3

No i więc... zastanawiam się, żeby:

• zrezygnować z intów i używać tylko floatów nawet w sytuacji, kiedy potrzebuję intów, tj. kiedy jedyną prawidłową wartością będą inty (np. wyobraźcie sobie grę w szachy).
• zrezygnować z wektorów 2D i oprzeć wszystko o wektory 3 wymiarowe (albo 4 wymiarowe: xyzw). Dzięki temu nie musiałbym osobnych funkcji do 2D robić, wystarczy, że użyłbym wektora 3D i zignorował wartości z i w (koszt - trochę więcej pamięci potrzebnej do zapisu takich wektorów).

Tylko o ile pomysł trzymania wszystkiego jako 4 wymiarowe wektory (nawet jeśli będą to pozycje 2D) wydaje mi się spoko, to jednak nie jestem przekonany co do rezygnacji z intów. Straciłbym część poprawności płynącej z silnego typowania, plus musiałbym konwertować to i tak do intów (chociaż teraz i tak muszę konwertować inty do floatów w pewnych miejscach).

Co o tym sądzicie?

Ja bym zostawił int i float, oraz osobne 2d i 3d. Nie wiem co konkretnie mógłbyś zyskać usuwając je.

Dla mnie vec3i i vec3 są za bardzo podobne. Dlaczego jedna ma i a druga nie ma nic?

Krajeski napisał(a):

Dla mnie vec3i i vec3 są za bardzo podobne. Dlaczego jedna ma i a druga nie ma nic?

No to możesz je nazwać DiscretVector oraz RealVector (na integer oraz float).

Krajeski napisał(a):

Dla mnie vec3i i vec3 są za bardzo podobne. Dlaczego jedna ma i a druga nie ma nic?

vec3 - nazwa inspirowana GLSL, a tam vec3 oznacza wektor floatów
chociaż tam widzę, że do intów jest ivec2, ivec3, ivec4 http://learnwebgl.brown37.net/12_shader_language/glsl_data_types.html

Riddle napisał(a):

Ja bym zostawił int i float, oraz osobne 2d i 3d. Nie wiem co konkretnie mógłbyś zyskać usuwając je.

No inty zostawię chyba, bo jednak w innych kontekstach używam intów, w innych floatów.
Inty wtedy kiedy chodzi o reprezentację czegoś na pozycji na konkretnym kafelku na mapie. Min. do szukania drogi używam intów.
Jednak do interpolacji potrzebuję już floatów i konwertuję, ale to chyba dobrze, bo to ma semantycznie inne znaczenie (Tj. na mapie albo coś jest na tym kafelku, albo innym, natomiast na potrzeby animacji robię tak, że jednostka się animuje płynnie z jednego kafelka na drugi).