Передача App Atom против Ref-Cursors в Om

При использовании Om кажется, что передача соответствующих частей состояния приложения дочерним компонентам — это фактически то же самое, что и отсутствие передачи состояния приложения, но использование ref-курсоров. Каков вариант использования ref-курсоров для передачи частей состояния приложения по цепочке?

Я прочитал все три учебника и концептуальный обзор в репозитории Om github, но не могу найти ответ на этот вопрос. Кажется, что можно использовать либо одно, либо другое и выполнить одно и то же (один либо определяет компонент с помощью (defn blah [_ owner] ...) и использует ref-курсоры, либо определяет компонент с помощью (defn blah [relevent-state owner] ...)

Может ли кто-нибудь пояснить, когда я хотел бы использовать курсор ссылки внутри компонента, а не просто передавать часть состояния приложения в этот компонент?


clojurescript om
person Community    schedule 25.01.2015    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Этот вопрос довольно старый, но я попробую.

Я считаю, что основным вариантом использования ref-курсоров является продвижение модульности и отделение глобального состояния приложения от компонентов. Он ограничивает область действия компонентов только данными, от которых они зависят, и ничем более.

Обычно вы передаете состояние приложения и любые обратные вызовы изменений вниз по дереву компонентов через реквизиты, как вы говорите. Следствием этого является то, что иерархия компонентов становится тесно связанной с «формой» состояния приложения. Иерархия компонентов должна соответствовать состоянию 1:1, иначе многие компоненты будут получать большие блоки данных и обратных вызовов, от которых зависят только несколько подкомпонентов, которые сами они могут никогда не использовать, т. е. вы можете обнаружить, что передаете части глобальное состояние вниз по цепочке компонентов только для того, чтобы компоненты, расположенные ниже, могли иметь к нему доступ. Эти компоненты используются в качестве канала для передачи состояния вниз, что не является идеальным, поскольку подвергает их воздействию состояния приложения, о котором они не знают. Вы рискуете сцепиться и потерять модульность.

С курсорами зависимости компонентов явно указываются каждым компонентом при монтировании. Курсоры — это черный ящик в состоянии приложения — сам компонент никогда не должен знать, где внутри приложения он находится. У вас есть полная гибкость в определении зависимостей компонента из любого места в состоянии приложения, не беспокоясь о передаче всех временных данных. Вы получаете односторонний поток данных без необходимости передавать обратные вызовы обновления в произвольно глубокие иерархии. Конечным результатом является превосходное разделение компонентов и модульность. В качестве бонуса у вас теперь есть единая точка в состоянии приложения, которую вы можете наблюдать за изменениями!

person Anchor    schedule 30.04.2015

arrow_upward
1
arrow_downward

Я использовал его, потому что при его обновлении вызываются все наблюдатели.

person Chaos Rules    schedule 25.01.2015
comment
Спасибо за пример использования, но на самом деле это не отвечает на мой вопрос относительно принятого варианта использования ref-cursors вместо простой передачи частей состояния приложения. - person ; 26.01.2015