Poprawne aktualizowanie stanu React - class component. (która wersja poprawna)

Question

Cześć, moje pytanie brzmi, jaka jest najlepsza praktyka kiedy używam setState?

//Przykładowy stan:
    this.state = {
      selectedCategory: "",
      overlayVisible: false,
    };

//Wersja 1:

setSelectedCategory = (category) => this.setState({ selectedCategory: category })
setOverlayVisible = () => this.setState((prevState) => ({ overlayVisible: !prevState.overlayVisible,}));

//Wersja 2:

  setSelectedCategory = (category) => this.setState((prevState) => ({
    ...prevState,
    selectedCategory: category,
  }));

  setOverlayVisible = () => this.setState((prevState) => ({
    ...prevState,
    overlayVisible: !prevState.overlayVisible,
  }));

Wiem że powinno się korzystać z poprzedniego stanu przy wszelakich licznikach.

Chodzi mi o najlepszą praktykę. Zawsze używać poprzedniego stanu?

Answer 1

Edit: moja odpowiedź dotyczy komponentów funkcyjnych. Jeśli chodzi o klasowe, to w komentarzu nieco piszę, jak to widzę.

Jeśli trzymasz w stanie dwie niezależne od siebie rzeczy, to nieużywanie poprzedniego stanu sprawi, że możesz utracić jedną z tych informacji. Zauważ, że w Twojej 1. wersji ustawienie selectedCategory oznacza automatycznie usunięcie overlayVisible. W chwili, gdy kopiujesz stary stan do nowego i jedynie nadpisujesz jego część (czyli 2. wersja) problem nie istnieje.

Więc tak, w większości przypadków należy się opierać na starym stanie.

Comments

Tylko że w komponentach klasowych Reacta aktualizacje stanu są mergowane, więc przekazanie samego selectedCategory do this.setState( .. ) powinno zachować również overlayVisible. Tego brakuje natomiast w aktualizacji stanu opartego o hook useState - tam merge stanu trzeba robić ręcznie (jeśli jest taka potrzeba).

Note

Unlike the setState method found in class components, useState does not automatically merge update objects.

---

Hm, dziwne, że nigdy tego nie ujednolicili, tbh.

Rzekłbym, że zachowanie, w którym nie dochodzi do merge'owania, jest zdecydowanie bardziej zrozumiałe. No i spójność między komponentami klasowymi a funkcyjnymi też jest argumentem za rozszerzaniem starego stanu. Zwłaszcza, jeśli kiedyś w przyszłości chcielibyśmy migrować.

---

Komponenty funkcyjne z założenia mają wiele stanów. W klasowych to jeden obiekt stąd różnice.

Przy migrowaniu na funkcyjne i tak wypadało by rozbić stan więc nie myślał bym w tych kategoriach.

---

Komponenty funkcyjne z założenia mają wiele stanów.

W jakim sensie? Można przecież mieć jeden stan w komponencie, np. jakiś licznik.

https://beta.reactjs.org/apis/react/useState#examples-basic

Przy migrowaniu na funkcyjne i tak wypadało by rozbić stan więc nie myślał bym w tych kategoriach.

Można skorzystać z reducera, żeby nie musieć rozbijać stanu - zwłaszcza jeśli jego kształt jest kontekstowo spójny.

---

Z wieloma stanami chodziło mi o to że lepiej zrobić kilka useState niż jeden useState z dużym obiektem. Może powinienem to poprawić. Komponenty funkcyjne z założenia mają wiele stanów atomowe stany. (Teraz będzie pasować nawet w przypadku jednego stanu  )

Można skorzystać z reducera, żeby nie musieć rozbijać stanu - zwłaszcza jeśli jego kształt jest kontekstowo spójny.

Można też używać useState z dużym obiektem. Jednak w obrębie klasowego komponentu zakładałbym że jednak niektóre z stanów nie są powiązane z innymi. Więc lepiej je separować co da możliwość w przyszłości na wyciągniecie części logiki do custom hooka ;) 

---

Dobrze, że React jest wewnętrznie spójnym frameworkiem, który nie zmienia znaczenia słów w zależności od kontekstu… ;)