не нужно на унижении других строить свою линию продвижения, имхо

более того, аудитория в том числе и реакта вам будет полезна, и они вряд ли перейдут с радостью на то, что формально позиционируется "врагом"

ИМХО

Да, неполиткорректненько 😊

Добрый вечер!
Поясните пожалуйста. К примеру в контроле $mol_card два поля status и content, но при определении этого контрола (к примеру вот тут - https://goo.gl/6o9CCw), используется поле Content. Почему так? Аналогично и с body vs Body в некоторых view.
P.S. Я пока составляю view.tree и не видел сгенерированный view.ts, может быть там будет ясно почему именно так.

Типичное именование:
с большой буквы - компонент.
с маленькой буквы - его содержимое.

Например:

<= Content $mol_view
    sub <= content /

Или:

<= Title $mol_view
    sub /
        <= title \

<= Content $mol_view
    sub <= content /

<= Title $mol_view
    sub /
        <= title \

Я про этот кусок:

<= Card $mol_card

    status <= status \

    Content <= Group $mol_row

        sub /

Почему status c маленькой, а Content с большой?

Вот пример демо кода:

<= User $mol_card
  content / <= user_name \
  status <= user_online_status \

Потому, что Content имеет тип "компонент" (кешируемый экземпляр наследника $mol_object), а status - строка. Компоненты с большой буквы, все остальные типы - с маленькой.

Мне не понятно как будет определено свойство content(): [] контрола $mol_card (https://github.com/eigenmethod/mol/tree/master/card)

Думаю лучше заглянуть в генерируемый view.tree.ts - там всё достаточно просто.

Да, спасибо. Там всё ясно.

/// Content $mol_view sub <= content

@ $mol_mem()

Content() {

  return $mol_view.make({

    sub : () => this.content() ,

  })

}

Добрый день!
Можно ли как-то сгенерировать view.tree.ts (напр. через cli)  для еще не подключенного компонента?

Можно отдельно скомпилировать любой компонент:

npm start пусть/к/компоненту

Мы собрали отзывы на ваш доклад "Объектное Реактивное Программирование" на РИТ++ 2017.

Ваш доклад оценили 10 пользователей нашего мобильного приложения, средний балл = 3,96 из 5.

Из пользователей, участвовавших в опросе после конференции, Ваш доклад оценили 42, они поставили докладу 3,29 балла из 5.

Вот какие отзывы они написали (стиль, орфография и пунктуация сохранены):
* Слишком сложно. Только для тех, кто пишет SPA.
* Просто не понравилось, я за ооп и реактивное программирование, но доклад мне показался про коммерческий фреймворк который так себе выглядит из паттернов увидел только конструкции декораторов. Где dic, фабрики, стратегии...
* Супер, только надо это осилить
* Хотелось бы проще для тех, кто совсем не в теме...
* Тема в целом интересная, но нападки на React и выводы про ""технологии, которые через пару лет никто не захочет использовать"" как-то не совсем... этичны что ли....

Согласен с тем, что сложно и очень непривычно. Но лично мне нравиться, как вы ввели достаточно разумные ограничения на процесс разработки и не "ведетесь" на тренды.

Навигация по экранам в приложении

Подскажите, как лушчше реализовать обновление состояния в hash, при переходе, к примеру, с вложенного экрана "Товары" на экран "Скидки"?

Состояние можно обновлять при закрытии экрана (удалять ключи), но переход между "Товары" и "Скидки" идет не через последовательно закрытие экранов "Заказ 002", "Заказы", а сразу.