Czy dumb component może renderować smart component

Witam. Zastanawiam się czy renderowanie Container/Smart/StateFull komponentu, w komponencie prezentacyjnym/dumb jest anty-paternem?. Czy są jakieś przeciwwskazania?, zastanawiam się czy wtedy ten podział nie traci sensu.

class SmartCmp extends Component {
  state = { smart: true };

  render() {
    return <p onClick={() => this.setState({ smart: false })}>bez znaczenia</p>;
  }
}

const DumbCmp = () => (
  <div>
    <h1>Komponent prezentacyjny</h1>
    <p>poniżej renderuje smart/state-full/container </p>
    <SmartCmp />
  </div>
);

A może lepszym rozwiązaniem jest taki pseudo HOC prezentacyjny?.

class SmartCmp extends Component {
  state = { smart: true };

  render() {
    return <p onClick={() => this.setState({ smart: false })}>bez znaczenia</p>;
  }
}

const DumbCmp = (props) => (
  <div>
    <h1>Komponent prezentacyjny</h1>
    <p>poniżej renderuje smart/state-full/container </p>
    {props.children}
  </div>
);

class ParentSmartCmp extends Component {
  render() {
    return (
      <DumbCmp>
        <SmartCmp />
      </DumbCmp>
    );
  }
}

Chętnie się dowie co sądzicie na ten temat. Które rozwiązanie według was jest lepsze?, i które powinno się stosować.

Witam. Zastanawiam się czy renderowanie Container/Smart/StateFull komponentu, w komponencie prezentacyjnym/dumb jest anty-paternem?

Moim zdaniem nie, w końcu enkapsulujesz stan i logikę w odrębnym komponencie. Czyli jeśli ci się zachce wymienić logikę, to wymienisz ją w komponencie stanowym, a nie będziesz ruszać komponentu prezentacyjnego. Czyli zasada pojedynczej odpowiedzialności będzie zachowana.

zastanawiam się czy wtedy ten podział nie traci sensu.

Ogólnie ten podział to takie uproszczenie, można go stosować dla wygody, ale można olać i kierować się intuicją, doświadczeniem, zdrowym rozsądkiem i ogólnoprogramistycznymi zasadami (np. wspomnianą zasadą pojedynczej odpowiedzialności, czyli S w SOLID).

Poza tym mam wrażenie, że podział smart/dumb components jest pretekstem dla wielu ludzi, żeby zaśmiecać komponenty stanowe. Czyli robią prezentacyjne ładne małe komponenty, a komponenty-kontenery traktują jako śmietniki na stan i na całą logikę, jaka im przyjdzie do głowy. Czyli trochę jak z MVC - miało być fajnie i miała być separacja między warstwami, a skończyło się na tym, że wielu ludzi stosuje MVC jako pretekst do robienia "god object" z kontrolera.

Więc tutaj wskazany jest zdrowy rozsądek.

Czy są jakieś przeciwwskazania?

Jak zajdzie potrzeba wyrenderowania czegoś na serwerze, to i tak wygeneruje się sam HTML, a nie będzie żadnego stanu. Ale przenosząc stan z jednego komponentu do drugiego i tak nie zlikwidujesz tego problemu. Ogólnie to stan jest problemem (także i pod innymi względami).

Które rozwiązanie według was jest lepsze?

Drugie jest bardziej elastyczne, ale wymaga więcej pisania.

Wyobraź sobie, że w wielu miejscach w projekcie będziesz renderować <DumbCmp />. I teraz tak - czy zawsze w DumbCmp będzie SmartCmp? Czy SmartCmp jest integralną częścią DumbCmp? Jeśli tak, to wtedy masz ciągłe powtarzanie kodu w wielu miejscach:

 <DumbCmp>
     <SmartCmp />
 </DumbCmp>

Chyba, że czasem w DumpCmp ma być SmartCmp, a czasem jakiś inny komponent Foo i ten komponent w środku ma być czymś wymienialnym:

 <DumbCmp>
     <Foo />
 </DumbCmp>

Wtedy dopiero podejście z props.children zaczyna być wygodne.

Zawsze to container component zarządza prezentacyjnymi. Jednak nic nie stoi na przeszkodzie żebyś wewnątrz komponentu prezentacyjnego użył smart componentu. Różnica powinna być tylko taka, ze twój prezentacyjny komponent z definicji nim nie zarządza. Twój smart component powinien sam w sobie robić swoją robotę, komunikuje się z odpowiednim serwisem itp. Rozwiązanie to może się przydać, gdy masz bardzo zagnieżdżona strukturę komponentów i musiał byś bąbelkować jakieś zdarzenie przez X poziomów do góry. Pamiętaj, najważniejsze żebyś był świadomy tego co robisz. Nie zapominaj tez w takich zagnieżdżonych strukturach o OnPush ChangeDetection

Wyobraź sobie ze gdzieś w zagnieżdżonej strukturze masz mieć jakaś wyszukiwarkę, niezależna od wszystkiego co się wokół dzieje. W takim przypadku możesz zrobić wyszukiwarkę w formie smart componentu która po wpisaniu frazy wywoła odpowiednie żądanie. I wtedy po kliknięciu takiego elementu gdzieś nawigujesz. Jakbyś nie zastosował smart componentu to byś znowu musiał przesyłać zdarzenie w górę struktury i wtedy odpytać serwis.