W jaki sposób połączony komponent Redux wie, kiedy wykonać ponowne renderowanie?

Prawdopodobnie brakuje mi czegoś bardzo oczywistego i chciałbym to wyjaśnić.

Oto moje zrozumienie.
W naiwnym elemencie reagującym mamy states& props. Aktualizacja statez setStateponownym renderowaniem całego komponentu. propssą w większości tylko do odczytu i ich aktualizowanie nie ma sensu.

W komponencie reagującym, który subskrybuje sklep Redux, za pośrednictwem czegoś podobnego store.subscribe(render), jest on oczywiście ponownie renderowany za każdym razem, gdy sklep jest aktualizowany.

React-redux ma pomocnika, connect()który wstrzykuje część drzewa stanu (który jest interesujący dla komponentu) i actionCreators jako propskomponent, zwykle poprzez coś w rodzaju

const TodoListComponent = connect(
  mapStateToProps,
  mapDispatchToProps
)(TodoList)

Ale rozumiejąc, że a setStatejest niezbędna TodoListComponentdo reagowania na zmianę drzewa stanu Redux (ponowne renderowanie), nie mogę znaleźć żadnego statelub setStatepowiązanego kodu w TodoListpliku komponentu. Brzmi mniej więcej tak:

const TodoList = ({ todos, onTodoClick }) => (
  <ul>
    {todos.map(todo =>
      <Todo
        key={todo.id}
        {...todo}
        onClick={() => onTodoClick(todo.id)}
      />
    )}
  </ul>
)

Czy ktoś może wskazać mi właściwy kierunek, czego mi brakuje?

PS Podążam za przykładem listy rzeczy do zrobienia dołączonej do pakietu Redux .

connectFunkcji generuje element owijający, który działa w sklepie. Gdy akcja jest uruchamiana, zostaje powiadomione wywołanie zwrotne komponentu opakowania. Następnie uruchamia twoją mapStatefunkcję i płytko porównuje obiekt wynikowy z tego czasu z obiektem wynikowym z ostatniego razu (więc gdybyś przepisał pole magazynu redux z tą samą wartością, nie spowodowałoby to ponownego renderowania). Jeśli wyniki są różne, przekazuje wyniki do „rzeczywistego” komponentu jako rekwizyty.

Dan Abramov napisał świetną, uproszczoną wersję connectat ( connect.js ), która ilustruje podstawową ideę, chociaż nie pokazuje żadnej optymalizacji. Mam również linki do wielu artykułów na temat wydajności Redux, w których omawiam kilka powiązanych pomysłów.

aktualizacja

React-Redux v6.0.0 wprowadził kilka poważnych wewnętrznych zmian w sposobie, w jaki podłączone komponenty odbierają dane ze sklepu.

W ramach tego napisałem post, który wyjaśnia, jak działa connectAPI i jego elementy wewnętrzne oraz jak zmieniały się w czasie:

Idiomatic Redux: Historia i implementacja React-Redux

Moja odpowiedź jest trochę poza lewym polem. Rzuca światło na problem, który doprowadził mnie do tego postu. W moim przypadku wyglądało na to, że aplikacja nie renderowała się ponownie, mimo że otrzymała nowe rekwizyty.
Twórcy Reacta mieli odpowiedź na to często zadawane pytanie, coś w rodzaju tego, że jeśli (sklep) został zmutowany, w 99% przypadków reakcja nie będzie ponownie renderowana. Jeszcze nic o pozostałych 1%. W tym przypadku mutacja nie miała miejsca.

TLDR;

componentWillReceivePropstak statemożna zsynchronizować plik z nowym props.

Krawędź obudowy: Po stateaktualizacji, następnie aplikacja ma ponownie uczynić!

Okazuje się, że jeśli twoja aplikacja używa tylko statedo wyświetlania swoich elementów, propsmoże aktualizować, ale statenie będzie, więc nie ma ponownego renderowania.

Miałem stateto zależne od propsotrzymanego od Redux store. Danych, których potrzebowałem, nie było jeszcze w sklepie, więc pobrałem je componentDidMount, jak trzeba . Otrzymałem rekwizyty z powrotem, kiedy mój reduktor zaktualizował sklep, ponieważ mój komponent jest połączony przez mapStateToProps. Ale strona nie została wyrenderowana, a stan wciąż był pełen pustych ciągów.

Przykładem tego jest sytuacja, w której użytkownik załadował stronę „edytuj post” z zapisanego adresu URL. Masz dostęp do postIdadresu z adresu URL, ale informacji storejeszcze nie ma, więc możesz je pobrać. Elementy na Twojej stronie są kontrolowanymi komponentami - więc wszystkie wyświetlane dane znajdują się w state.

Korzystając z Redux, dane zostały pobrane, sklep został zaktualizowany, a komponent jest connectedytowany, ale aplikacja nie odzwierciedlała zmian. Przy bliższym przyjrzeniu się propsotrzymaliśmy, ale aplikacja nie została zaktualizowana. statenie zaktualizowany.

Cóż, propsbędzie aktualizować i propagować, ale statenie będzie. Musisz konkretnie powiedzieć, stateaby zaktualizować.

Nie możesz tego zrobić w render(), a componentDidMountjuż skończyłeś swoje cykle.

componentWillReceivePropsto miejsce, w którym aktualizujesz statewłaściwości, które zależą od zmienionej propwartości.

Przykładowe zastosowanie:

componentWillReceiveProps(nextProps){
  if (this.props.post.category !== nextProps.post.category){
    this.setState({
      title: nextProps.post.title,
      body: nextProps.post.body,
      category: nextProps.post.category,
    })
  }      
}

Muszę wypowiedzieć się na temat tego artykułu, który wyjaśnił mi rozwiązanie, o którym nie wspomniały dziesiątki innych postów, blogów i repozytoriów. Każdy, kto miał problem ze znalezieniem odpowiedzi na ten ewidentnie niejasny problem, oto jest:

Metody cyklu życia komponentów ReactJs - szczegółowe omówienie

componentWillReceivePropsto miejsce, w którym będziesz aktualizować, stateaby być zsynchronizowanym z propsaktualizacjami.

Po stateaktualizacji, następnie pola w zależności od state wykonania ponownego renderowania!

Ta odpowiedź jest podsumowaniem artykułu Briana Vaughna zatytułowanego You Probably Don't Need Derived State (07 czerwca 2018).

Wyprowadzanie stanu z rekwizytów jest anty-wzorcem we wszystkich jego formach. W tym starsze componentWillReceivePropsi nowsze getDerivedStateFromProps.

Zamiast wyprowadzać stan z rekwizytów, rozważ następujące rozwiązania.

Dwa zalecenia dotyczące najlepszych praktyk

function EmailInput(props) {
  return <input onChange={props.onChange} value={props.email} />;
}

// parent class
class EmailInput extends Component {
  state = { email: this.props.defaultEmail };

  handleChange = event => {
    this.setState({ email: event.target.value });
  };

  render() {
    return <input onChange={this.handleChange} value={this.state.email} />;
  }
}

// child instance
<EmailInput
  defaultEmail={this.props.user.email}
  key={this.props.user.id}
/>

Dwie alternatywy, jeśli z jakiegokolwiek powodu zalecenia nie sprawdzają się w Twojej sytuacji.

class EmailInput extends Component {
  state = {
    email: this.props.defaultEmail,
    prevPropsUserID: this.props.userID
  };

  static getDerivedStateFromProps(props, state) {
    // Any time the current user changes,
    // Reset any parts of state that are tied to that user.
    // In this simple example, that's just the email.
    if (props.userID !== state.prevPropsUserID) {
      return {
        prevPropsUserID: props.userID,
        email: props.defaultEmail
      };
    }
    return null;
  }

  // ...
}

class EmailInput extends Component {
  state = {
    email: this.props.defaultEmail
  };

  resetEmailForNewUser(newEmail) {
    this.setState({ email: newEmail });
  }

  // ...
}

jak wiem jedyne co robi Redux, przy zmianie stanu sklepu wywołuje componentWillRecieveProps, jeśli twój komponent był zależny od zmutowanego stanu i wtedy powinieneś zmusić komponent do aktualizacji, tak jest

1-magazynowa zmiana stanu 2-wywołanie (componentWillRecieveProps (() => {3-składnikowa zmiana stanu}))