Mithril js - схема связи между компонентами связи

Question

У меня есть другая реализация кросс-компонентной связи здесь http://jsfiddle.net/c641oog2/, чем то, что описано здесь: http://lhorie.github.io/mithril/components.html#librarization. Цель состоит в том, чтобы создать легко интегрируемые & масштабируемые (для повторного использования в других компонентах) компоненты, то есть библиотеку.

Основные части моего кода:

var autocompleter = function(options) { 
    ... 
    autocompleter.vm = { 
    list: m.prop(options.list || []), 
    observers: m.prop(options.observers || []), 
    ... 
select: function(item) { 
    for(observer in autocompleter.vm.observers()) { 
    autocompleter.vm.observers()[observer](item); //notify all observers of selection 
    } 
} 
    //initialization later on... 
    this.userAC = new autocompleter({list: this.users(), observers: [this.selectedUser]}) 

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

Мои вопросы:

1. Если бы вам пришлось выбирать между этими двумя реализации, почему вы выбираете один над другим?
2. В модели функционального программирования есть концепция ООП, такая как шаблон наблюдателя, нахмурившийся?
3. Есть ли более тонкий, но масштабируемый способ реализации этого в FP/с использованием другого шаблона?

Answer 1

Приятный пример. Похоже на меня. Небольшой намек на ввод символов с помощью «j», «b» или «m» позволит избежать необходимости считывать весь код или предполагать, что пример сломан;)

Для установки концентратора/панели мониторинга и подпункты, шаблон наблюдателя просто добавляет дополнительные накладные расходы без каких-либо преимуществ развязки, поскольку приборная панель должна инициировать подзапросы в любом случае.

Было бы более разумным, если подпроект «project» будет наблюдать подзону пользователя. Это обеспечило бы сложную и многоразовую логику между подзонами с легкой приборной панелью, ограниченной инициацией.

Answer 2

Лично я предпочитаю «чистую» версию, а не шаблон наблюдателя. Я думаю, что концептуально это проще. Там нет кросс-компонентной коммуникации, все вертикально вверх и вниз между родителями и детьми.

Кроме того, вы нарушаете (на мой взгляд) идею о том, что состояние пользовательского интерфейса является данными и поэтому идеально никогда не дублируется.

Это означает, что если вы создаете новые компоненты, которые хотят взаимодействовать с остальными, все они должны сохранять копии выбранного состояния, а не все, наблюдая за одной моделью состояния пользовательского интерфейса.