Luźne zapiski o uniwersalności struktur
Struktury danych są najważniejsze.
Powinny być zuniformizownane na poziomie co najmniej projektu.
Czyli np.:
- Załózmy, że mamy komponent w React (Angular itp.), który przyjmuje na wejściu listę obiektów do wyświetlenia. Jeśli w jednym komponencie właściwość ta nazywa się "items" to w drugiem tak samo powinna się nazywać (czyli nie np. `list` albo `listItems` ale właśnie `items`. Oczywiście jest to arbitralne. Ważne, żeby wszędzie było tak samo.
- Jeśli nie jest możliwe zuniformizowanie właściwości, warto zadbać o pewnego rodzaju adapter. Adapterem może być np. Higher Order Component w React. Np.
https://jsfiddle.net/69z2wepo/46661/
Może to być również funkcja dostępowa (geter, selektor), np.
https://jsfiddle.net/yw3mz5on/
Jeśli to możliwe, to należy zachowywać spójność w strukturach danych na poziomie więcej niż jednego projektu. Ponieważ:
- większa reużywalność poszczególnych komponentów, modułów, funkcji.
- większa intuicyjność
- tworzymy "efekt platformy", gdzie poszczególne części(komponenty, funkcje, moduły etc.) będą pasować do siebie jak klocki.
- łatwe przenoszenie danych pomiędzy projektami
- w dynamicznym języku jakim jest JavaScript uniwersalne struktury danych zastępują statyczne typowanie. To taki rozszerzony duck typing - nie tylko w odniesieniu do wywołania metod obiektów, ale również w odniesieniu do zwykłych obiektów i wartości w obiektach (przez "obiekt" mam na myśli teraz użycie obiektów JavaScript jako słownika/hasha/struktury danych a nie w sensie OOP).
- Należy zachowywać zasadę KISS w nazewnictwie. Np. porównując DOM API i jQuery.
DOM API ma dziwne, niespotykane bądź skomplikowane nazwy metod/właściwości, np. getElementById, querySelectorAll, innerHTML, addEventListener
jQuery ma proste jak drut, np. $ (znak dolara), html(), on()
Dlatego jQuery jest bardziej proste i przez to lepsze. Kieruje się uniwersalnymi zasadami zamiast kreować tysiące różnych dziwnie nazwanych metod.
jQuery szybciej można się nauczyć
jQuery łatwiej można zamockować.
łatwiej zrobić swoją bibliotekę kompatybilną z jQuery
itp.
- można się wzorować na innych bibliotekach.
można (ale nie trzeba!) się wzorować na interfejsie jQuery. Można się wzorować na interfejsie Gulpa. Na interfejsie Angulara. Na interfejsie Reacta. Na czymkolwiek co popularne. Jeśli to możliwe, warto dbać o kompatybilność z istniejącymi rozwiązaniami. Jednak nie za wszelką cenę. Trzeba wyczuć sytuację, kiedy kompatybilność z czymś wcześniejszym będzie dawała nam potencjalne korzyści, a kiedy będzie ona kulą u nogi. Pamiętajmy o: wzorcu projektowym adapter; o kompozycji w OOP (zamiast dziedziczenia); o innych rzeczach, których możemy użyć do tego, żeby zjeść ciastko i mieć ciastko.
Powinny być zuniformizownane na poziomie co najmniej projektu.
Czyli np.:
- Załózmy, że mamy komponent w React (Angular itp.), który przyjmuje na wejściu listę obiektów do wyświetlenia. Jeśli w jednym komponencie właściwość ta nazywa się "items" to w drugiem tak samo powinna się nazywać (czyli nie np. `list` albo `listItems` ale właśnie `items`. Oczywiście jest to arbitralne. Ważne, żeby wszędzie było tak samo.
- Jeśli nie jest możliwe zuniformizowanie właściwości, warto zadbać o pewnego rodzaju adapter. Adapterem może być np. Higher Order Component w React. Np.
https://jsfiddle.net/69z2wepo/46661/
Może to być również funkcja dostępowa (geter, selektor), np.
https://jsfiddle.net/yw3mz5on/
Jeśli to możliwe, to należy zachowywać spójność w strukturach danych na poziomie więcej niż jednego projektu. Ponieważ:
- większa reużywalność poszczególnych komponentów, modułów, funkcji.
- większa intuicyjność
- tworzymy "efekt platformy", gdzie poszczególne części(komponenty, funkcje, moduły etc.) będą pasować do siebie jak klocki.
- łatwe przenoszenie danych pomiędzy projektami
- w dynamicznym języku jakim jest JavaScript uniwersalne struktury danych zastępują statyczne typowanie. To taki rozszerzony duck typing - nie tylko w odniesieniu do wywołania metod obiektów, ale również w odniesieniu do zwykłych obiektów i wartości w obiektach (przez "obiekt" mam na myśli teraz użycie obiektów JavaScript jako słownika/hasha/struktury danych a nie w sensie OOP).
- Należy zachowywać zasadę KISS w nazewnictwie. Np. porównując DOM API i jQuery.
DOM API ma dziwne, niespotykane bądź skomplikowane nazwy metod/właściwości, np. getElementById, querySelectorAll, innerHTML, addEventListener
jQuery ma proste jak drut, np. $ (znak dolara), html(), on()
Dlatego jQuery jest bardziej proste i przez to lepsze. Kieruje się uniwersalnymi zasadami zamiast kreować tysiące różnych dziwnie nazwanych metod.
jQuery szybciej można się nauczyć
jQuery łatwiej można zamockować.
łatwiej zrobić swoją bibliotekę kompatybilną z jQuery
itp.
- można się wzorować na innych bibliotekach.
można (ale nie trzeba!) się wzorować na interfejsie jQuery. Można się wzorować na interfejsie Gulpa. Na interfejsie Angulara. Na interfejsie Reacta. Na czymkolwiek co popularne. Jeśli to możliwe, warto dbać o kompatybilność z istniejącymi rozwiązaniami. Jednak nie za wszelką cenę. Trzeba wyczuć sytuację, kiedy kompatybilność z czymś wcześniejszym będzie dawała nam potencjalne korzyści, a kiedy będzie ona kulą u nogi. Pamiętajmy o: wzorcu projektowym adapter; o kompozycji w OOP (zamiast dziedziczenia); o innych rzeczach, których możemy użyć do tego, żeby zjeść ciastko i mieć ciastko.
Komentarze
Prześlij komentarz