Kiedy stosować komponenty React oparte na klasie ES6 a funkcjonalne komponenty React ES6?

Po spędzeniu czasu na nauce React rozumiem różnicę między dwoma głównymi paradygmatami tworzenia komponentów.

Moje pytanie brzmi: kiedy powinienem użyć którego i dlaczego? Jakie są zalety / kompromisy jednego nad drugim?

Klasy ES6:

import React, { Component } from 'react';

export class MyComponent extends Component {
  render() {
    return (
      <div></div>
    );
  }
}

Funkcjonalny:

const MyComponent = (props) => {
    return (
      <div></div>
    );
}

Myślę, że jest funkcjonalny, ilekroć nie ma stanu, którym mógłby manipulować ten komponent, ale czy to jest to?

Zgaduję, że jeśli użyję jakichkolwiek metod cyklu życia, może być lepiej, aby użyć komponentu opartego na klasach.

Masz dobry pomysł. Idź z funkcjonalnością, jeśli twój komponent nie robi nic więcej niż przyjmowanie niektórych rekwizytów i renderowanie. Możesz myśleć o nich jako o czystych funkcjach, ponieważ zawsze będą renderować i zachowywać się tak samo, biorąc pod uwagę te same rekwizyty. Nie dbają też o metody cyklu życia ani nie mają własnego stanu wewnętrznego.

Ponieważ są one lekkie, pisanie tych prostych elementów jako elementów funkcjonalnych jest dość standardowe.

Jeśli komponenty wymagają większej funkcjonalności, np. Utrzymania stanu, użyj klas.

Więcej informacji: https://facebook.github.io/react/docs/reusable-components.html#es6-classes

EDYCJA : Wiele z powyższych było prawdą, dopóki nie wprowadzono React Hooks.

• componentDidUpdatemożna zreplikować za pomocą useEffect(fn), gdzie fnjest funkcja uruchamiana przy ponownym renderowaniu.

• componentDidMountmetody mogą być replikowane useEffect(fn, []), gdzie fnjest funkcja uruchamiana przy ponownym renderowaniu, i []jest tablicą obiektów, dla których komponent ponownie się wyrenderuje, tylko wtedy, gdy przynajmniej jedna zmieniła wartość od poprzedniego renderowania. Ponieważ ich nie ma, useEffect()uruchamia się raz na pierwszym montażu.

• statemoże być zreplikowany useState(), którego wartość zwracaną można zniszczyć do odwołania do stanu i funkcji, która może ustawić stan (tj const [state, setState] = useState(initState).). Przykład może to wyjaśnić jaśniej:

const Counter = () => {
  const [count, setCount] = useState(0)

  const increment = () => { 
    setCount(count + 1);
  }

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={increment}>+</button>
    </div>
  )
}

default export Counter

Jeśli chodzi o zalecenie, kiedy stosować klasę zamiast komponentów funkcjonalnych, Facebook oficjalnie zaleca używanie komponentów funkcjonalnych tam, gdzie to możliwe . Nawiasem mówiąc, słyszałem wiele osób dyskutujących o nieużywaniu komponentów funkcjonalnych ze względu na wydajność, a konkretnie z tego powodu

„Funkcje obsługi zdarzeń są redefiniowane dla poszczególnych renderów w komponentach funkcjonalnych”

Chociaż to prawda, zastanów się, czy Twoje komponenty naprawdę renderują z taką prędkością lub głośnością, że byłoby to warte zaniepokojenia.

Jeśli tak, możesz zapobiec przedefiniowaniu funkcji za pomocą useCallbacki useMemohooków. Należy jednak pamiętać, że może to pogorszyć działanie (mikroskopowo) kodu .

Ale szczerze mówiąc, nigdy nie słyszałem o ponownym definiowaniu funkcji stanowiących wąskie gardło w aplikacjach React. Przedwczesne optymalizacje są źródłem wszelkiego zła - martw się o to, gdy jest to problem

Zawsze staraj się używać funkcji bezstanowych (komponentów funkcjonalnych), gdy tylko jest to możliwe. Istnieją scenariusze, w których musisz użyć zwykłej klasy React:

• Komponent musi utrzymać stan
• Komponent renderuje zbyt wiele i należy to kontrolować za pośrednictwem shouldComponentUpdate
• Potrzebujesz komponentu kontenera

AKTUALIZACJA

Istnieje teraz klasa React PureComponent, którą można rozszerzyć (zamiast Component), która implementuje swoją własną, shouldComponentUpdatektóra dba o porównanie płytkich rekwizytów. Czytaj więcej

AKTUALIZACJA Marzec 2019

https://overreacted.io/how-are-function-components-different-from-classes/

AKTUALIZACJA Luty 2019:

Wraz z wprowadzeniem haków React wydaje się, że zespoły React chcą, abyśmy korzystali z funkcjonalnych komponentów, gdy tylko jest to możliwe (co lepiej odpowiada funkcjonalnej naturze JavaScript).

Ich motywacja:

1.) It’s hard to reuse stateful logic between components
2.) Complex components become hard to understand
3.) Classes confuse both people and machines

Funkcjonalny komponent z haczykami może zrobić prawie wszystko, co może zrobić komponent klasy, bez żadnej z wymienionych powyżej wad.

Zalecam ich użycie, gdy tylko będzie to możliwe.

Oryginalna odpowiedź

Komponenty funkcjonalne nie są bardziej lekkie niż komponenty oparte na klasach, „działają dokładnie jak klasy”. - https://github.com/facebook/react/issues/5677#issuecomment-241190513

Powyższe łącze jest trochę przestarzałe, ale dokumentacja React 16.7.0 mówi, że komponenty funkcjonalne i klasowe:

„są równoważne z punktu widzenia React”. - https://reactjs.org/docs/components-and-props.html#stateless-functions

Zasadniczo nie ma różnicy między komponentem funkcjonalnym a komponentem klasy, który właśnie implementuje metodę renderowania, inną niż składnia.

W przyszłości (cytując powyższy link) „my [React] możemy dodać takie optymalizacje”.

Jeśli próbujesz zwiększyć wydajność, eliminując niepotrzebne rendery, oba podejścia zapewniają wsparcie. memodla komponentów funkcjonalnych i PureComponentdla klas.

- https://reactjs.org/docs/react-api.html#reactmemo

- https://reactjs.org/docs/react-api.html#reactpurecomponent

To naprawdę zależy od ciebie. Jeśli chcesz mniej płyty kotła, działaj. Jeśli kochasz programowanie funkcjonalne i nie lubisz zajęć, wybierz funkcjonalność. Jeśli chcesz uzyskać spójność między wszystkimi komponentami w bazie kodu, idź z klasami. Jeśli masz dość refaktoryzacji komponentów od funkcjonalnych do klasowych, kiedy potrzebujesz czegoś takiego state, idź z klasami.

Od React 16.8 termin Bezstanowe elementy funkcjonalne są mylące i należy ich unikać, ponieważ nie są one już bezpaństwowcami ( React.SFC przestarzałe , Dan Abramov na React.SFC ), mogą mieć stan, mogą mieć haki (które działają jak metody cyklu życia), pokrywają się one mniej więcej z komponentami klasy

Komponenty oparte na klasach

• stan
• metody cyklu życia
• memoization with React.PureComponent

Komponenty funkcjonalne:

• state ( useState , useReducer hooks)
• metody cyklu życia (za pomocą haczyków useEffect , useLayoutEffect )
• zapamiętywanie za pomocą notatki HOC

Dlaczego wolę komponenty Funtional

• React dostarczyć hak useEffect który jest bardzo jasny i zwięzły sposób, aby połączyć componentDidMount, componentDidUpdatea componentWillUnmountmetody cyklu życia
• Za pomocą haczyków można wyodrębnić logikę, którą można łatwo udostępnić między komponentami i przetestować
• mniej zamieszania na temat określania zakresu

Reaguj motywację, dlaczego używasz haczyków (tj. Elementów funkcjonalnych).