Comments 8
Проблема и этой статьи, и документации - нет постановки задачи. Совершенно непонятно, зачем нужен этот фреймворк и какую проблему предшественников призван решать. Вы сходу ныряете в код, в котором вроде примерно понятно что происходит, но непонятно зачем и почему. В документации то же самое: открываю раздел "быстрый старт" - npm блабла, import тратата. Но зачем? Какие я должен получить преимущества в итоге?
Походив по ссылкам, я набрел на статью 2-летней давности, которая пытается отвечать на этот вопрос. Но во-первых, как-то многословно, сходу въехать сложно. А во-вторых, её надо было ещё найти. Большинство читателей вряд ли стали заморачиваться.
Зашёл в документацию - ничего не понял. Что это за инструмент? Какую проблему решает? Даже несколько раз кликнул на главную с целью найти описание. Но описания нет, сразу пишем какой-то код.
Смотрите, я немного упростил ваш чертёж, используя view.tree:
$my_greeter $mol_view
data?next \
greet_message @ \Hello
sub /
<= Greet $mol_button_minor
title @ \Greet me
click?event <=> greet?event null
<= Message $mol_paragraph
title <= message \namespace $.$$ {
export class $my_greeter extends $.$my_greeter {
greet() {
this.message( this.greet_message() )
}
}
}Как видите, кода получилось гораздо меньше. При этом синтаксис мотивировал нас написать везде говорящие имена, а не белиберду. Идём дальше..
хочу, чтобы компонент можно было стилизовать
Любой компонент на любом уровне вложенности уже можно стилизовать либо через css, либо через $mol_style (который генерирует тот же CSS). Например:
/* Для примера экземпляр $my_greeter имеет имя welcome в компоненте $my_app */
[my_app_welcome] {
стили для корневого элемента компонента
}
[my_app_welcome_greet] {
стили для кнопки
}
[my_app_welcome_message] {
стили для параграфа
}Вы остановились на стилизации, но можно ведь пойти и дальше, меняя в том числе и поведение компонента.
зачем что-то добавлять в DOM, если данных еще нет?
Чтобы показать пользователю, что данных ещё нет. Обычно это выглядит как анимашка внутри некоторого (предназначенного для загружаемого контента) интерфейса.
Мне же больше нравится вариант, когда загрузка вообще никак не связана с рендерингом.
То есть у вас возможны ошибки двух типов:
Загрузили что-то и не показали (лишняя загрузка).
Показали то, что забыли загрузить.
В системах, где инициатором загрузки является отображение, такие ошибки невозможны в принципе.
Компонент видит только свой скоуп и работает только с ним, считая, что вокруг никого нет. Это позволяет спокойно выполнять смешивание, не опасаясь сломать жесткие связи между компонентами
Это классный принцип, весь $mol на нём построен. Но для его раоты необходим автотрекинг зависимостей, так как связи становятся строго динамическими.
По умолчанию, скоуп делит свое содержимое с другими связанными скоупами, таким образом позволяя компонентам иметь доступ, например, к общему роуту.
Емнип так работали контексты в AngularJS. И частая проблема с этим подходом - неявная зависимость компонента на окружение. Это когда компонент в одном месте работает исправно, а при переносе в другое место вдруг ломается, ибо родительские контексты сложились иначе.
Правда вот, SSR превратился в нетривиальную задачу
Не понятно почему. Достаточно отрендерить через JSDOM, получить DOM и его сериализовать.
Если фреймворк вас заинтересовал, или у вас есть предложения по его развитию - всегда пожалуйста.
Ещё через пару лет вы переизобретёте $mol, где уже как 5 лет есть это всё и даже больше. Не буду предлагать вам скипнуть пару лет и сразу перейти на $mol. Но подсмотреть что-то из него всё же стоит.)
Смотрите, я немного упростил ваш чертёж, используя view.tree:
Обуждение синтаксиса в данном случае бесперспективная тема. $mol фактически предлагает выучить новый язык программирования (надеюсь, только шаблонов). Chorda это хорошо знакомые JS/TS.
Вы остановились на стилизации, но можно ведь пойти и дальше, меняя в том числе и поведение компонента.
Пойти дальше не позволили рамки статьи :) Переопределение поведения, конечно, есть. Но это сложная и любопытная тема.
1. Загрузили что-то и не показали (лишняя загрузка).
2. Показали то, что забыли загрузить.
Я правильно понимаю, что вы не рассматриваете варианты агрегации данных перед отображением?
В системах, где инициатором загрузки является отображение, такие ошибки невозможны в принципе.
Здесь огромное спасибо EdgarAbgaryan за хороший пример на тему того, что обычно поисходит, когда инициатором загрузки является отображение.
Я не утверждаю, что инициировать загрузку через отображение нельзя, но рассматриваю ее только как частный случай, скорее даже оптимизацию
Это когда компонент в одном месте работает исправно, а при переносе в другое место вдруг ломается, ибо родительские контексты сложились иначе.
Очень интересная тема. Тут два момента:
1. Если речь про неявную завязку на контекст, то это изначально плохо. Не надо так делать
2. При явном же подключении необходим контроль типов контекста. Обычно этого достаточно
И, кстати, проблема характерна не только для Angular
Не понятно почему. Достаточно отрендерить через JSDOM, получить DOM и его сериализовать.
Тут речь скорее о восстановлении компонентов на стороне браузера
Ещё через пару лет вы переизобретёте $mol, где уже как 5 лет есть это всё и даже больше
Я все же очень рассчитываю, что Chorda идет по другому пути нежели $mol. Сосуществование с другими библиотеками мне нравится больше, чем война с ними
Но подсмотреть что-то из него всё же стоит.)
Подсматриваем, конечно :) На данный момент интересен кейс использования $mol в качестве отрисовщика
$mol фактически предлагает выучить новый язык
Выучили же люди как-то JSX и ничего, не померли.
Я правильно понимаю, что вы не рассматриваете варианты агрегации данных перед отображением?
Только отображению известно какую часть каких данных оно собирается показать.
пример на тему того, что обычно поисходит, когда инициатором загрузки является отображение.
Тут всё же проблема не в отображении, а в кривом апи Реакта.
При явном же подключении необходим контроль типов контекста. Обычно этого достаточно
Типы могут совпасть и случайно. Классический пример - глобальная переменная name строкового типа.
Тут речь скорее о восстановлении компонентов на стороне браузера
Гидратация? SSR нужен роботам, а не браузерам. Браузеру быстрее скачать данные без html-мишуры и отрендерить нужную их часть.
На данный момент интересен кейс использования $mol в качестве отрисовщика
Пожалуй единственный фреймворк, который кроме "мой синтаксис лучше - это ж очевидно" приносит реальное решение реальных проблем так это Крэнк. На данный момент, это, имо, самый трезвый подход к решению веба. https://crank.js.org/blog/introducing-crank
Chorda 3.0. Осенний релиз