Przechodzę przez to OM tutorial, ale nie jest dla mnie jasne, kiedy używać komponentów OM w porównaniu do funkcji prostych (w szczególności makro om/komponent).Komponenty OM vs funkcje proste
Tutorial pisze:
Pierwszy argument to funkcja, która pobiera dane stanu aplikacji i podkład React komponentu, o nazwie właściciela. Funkcja ta musi powrotu składnik Om - czyli modelu interfejsu om/IRender, jak om.core/części makro generuje
; here the function (fn [app owner]) indeed returns an OM component
(om/root
(fn [app owner]
(om/component (dom/h2 nil (:text app))))
app-state
{:target (. js/document (getElementById "app"))})
W kolejnym rozdziale wybrać następujący przykład pętli renderowania na liście:
; this one does not return an om component (or does it?). it returns a virtual dom
(om/root
(fn [app owner]
(apply dom/ul nil
(map (fn [text] (dom/li nil text)) (:list app))))
app-state
{:target (. js/document (getElementById "app0"))})
Tutaj, mamy w zasadzie tylko przekazujących (wirtualny) DOM bezpośrednio nie zawinięty w komponencie OM, więc pytanie byłoby: Dlaczego makro om/komponent istnieje? Makro po prostu pomaga nam w reifikacji funkcji IRender, ale wydaje się, że możemy po prostu użyć do tego zwykłych funkcji. Chciałbym rektyfikować komponenty OM, które mają stan cyklu życia (lub potrzebują właściciela, aby wywoływać get-props), ale komponenty, które potrzebują tylko stworzyć wirtualną domenę Wolę używać prostych funkcji (więc nie potrzebuję kompilacji/kompilacji) wszystkie funkcje do tworzenia mojej wirtualnej domeny). Czego tu mi brakuje? Dlaczego makro jest nadal przydatne (i nie widzę tego).
Dobra, to rozumiem. Więc makro może być tam, kiedy chcesz zawinąć prosty składnik reakcji w komponent OM. Być może przyszłe wersje OM będą mieć nieznacznie różne semantyki w makrze om/component, więc lepiej użyć makra, nawet wszystko, co musisz zrobić, to zwrócić komponent reagowania. – shaft