Wpis z mikrobloga

Postanowiłem popełnić kilka wpisów związanych z Reactem, Reactem-Nativem oraz okolic. Nie chce mi się prowadzić bloga, więc wpisy będą bezpośrednio tutaj. Nie chcę mieć swojego tagu (przynajmniej póki co), ale znajdziecie mnie pod tagami z tego wpisu i mogę robić komentarze taktyczne do wołania ( ͡° ͜ʖ ͡°).

Na dzisiaj React i no-bind rule.

TL;DR Nie należy w propsach bezpośrednio bindować, wstawiać funkcji (najczęściej arrow function), wstawiać JSXa ani wpisywać bezpośrednio nieprymitywnej wartości (z prymitywami też polecam stosować tą zasadę), bo przy każdym rerenderze React będzie tworzyć nową instancję metody bind, funkcji albo nowe miejsce w pamięci dla wartości.

Niechlubnie mówiąc natknąłem się na to, bo wariował mi komponent w React-Native, a szukając odpowiedzi trafiłem na post jednego z inżynierów Facebooka na ten temat. Sahrens napisał, że przekazując w ten sposób powyższe rzeczy React widzi je jako np Stateless Component, a nie jako zwykłą funkcję i w związku z tym za każdym razem tworzy jej nową instację. Nawet w eslincie znajdziecie plugin, który będzie to sprawdzać. Dlatego należy posłużyć się praktyką prebindowania ( ͡° ͜ʖ ͡°). Uważam to za ciekawe, bo nawet Facebook w swojej dokumentacji tego nie umieścił, a praktycznie każdy przykład z ich strony łamie tą zasadę. Prawdopodobnie dlatego żeby zwiększyć czytelność przykładów, jednak może to wprowadzić małe zamieszanie przy kształtowaniu swoich nawyków.

Rozwiązanie dla bindów:
-Prebind w konstruktorze np this.refresh = this.refresh.bind(this). Proste, ale brzydkie ^^
-Definiowanie metody za pomocą arrow function, więc nie trzeba bindować. Jedno z lepszych rozwiązań(zakładam, że najmarniej es6 macie w projekcie).
-Ficzery z ES8+ dekoratory np @autobind, którym można zbindować metodę albo całą klasę. Fajne, ale to es8 i nie każdemu siada.

Rozwiązania dla arrow function w propsie:
-No definiujecie arrow function jako metodę i korzystacie z niej. Dokładnie jak w punkcie 2 przy bindowaniu.

Rozwiązanie dla definiowania w propsach - zadeklaruj wcześniej stałą/zmienną i się nią posłuż. No ale o co chodzi, jakie przekazywanie inline'owe zmiennych, po co ( ͡° ͜ʖ ͡°). Załóżmy, że wstawiasz w propsie this.object ? this.object : { }. Ten pusty obiekt powinien być zadeklarowany wcześniej, bo będzie się tworzyło dla niego nowe miejsce w pamięci (a właściwie dla jego instancji) za każdym re-renderem.

Jeszcze bonus do refsów. Tak jak pisałem dla prymitywów też to robimy i według Sahrensa powinniśmy przekazać funkcję zwracającą stringa zamiast przekazywania stringa.

Te zabiegi przyśpieszą działanie aplikacji, mogą rozwiązać jakieś bugi z re-renderem (np. ładowanie zdjęć z sieci przy każdym re-renderze). Więcej na ten temat znajdziecie w internetach, chociaż nie ma tego za dużo. Podrzucam jeszcze link do wątku na githubie, gdzie znajduje się post tego inżyniera co o nim pisałem ( ͡° ͜ʖ ͡°) https://github.com/facebook/react-native/issues/13602

#react #reactnative #programowanie #naukaprogramowania #javascript #webdev
  • 8
@MrRuby Właśnie dopiero po napisaniu zobaczyłem, że opisując to po Polsku, bez przykładów i z moją składnią ciężko załapać o co chodzi :< następnym razem zrobię to lepiej, ale póki co jak ktoś nie może rozszyfrować tego wpisu to niech po prostu googlnie "react no-bind rule" to znajdzie podobne wpisy w przystępniejszej wersji ^^
@PrawyKuba: Dokładnie, chociaż oni nie opisali tego kompleksowo, a zalinkowany plugin też nie ogarnia przekazywania inline'owo wartości. Następny post będzie prawdopodobnie zbiorem fajnych rzeczy i agregatów jak np awesome react, więc i style guide'y się tam pojawią ( ͡° ͜ʖ ͡°)
@MKu8ar: Nigdzie tego nie napisałem. Rerender robił się bez powodu i powodował ponowne ładowanie zdjęć z headera w liście, a że był wykorzystany blur to po prostu się blurowały. Błąd, który nie obniżał zbytnio wydajności, nie kreszował, nie pojawiał się nawet jako warning. Ot, głupota psująca UX.
@xDrope: Troche offtop ale co powiecie na używanie style w componentach, bo ostatnio miałem przez to pszypał, a uważam, że dodanie pewnych własności css przez style jest o wiele czytelniejsze niż tworzenie całej klasy dla jednej/dwóch właściwości?