Комментарии 13
Я обычно презентую $mol, выпущенный пару лет назад, как фреймворк будущего. Давайте посмотрим, куда движется Vue..
3.0 будет поддерживать компоненты на основе классов изначально
Что было изначально в $mol. Любой компонент — не более чем класс, реализующий определённый АПИ.
Кодовая база 3.x сама будет написана на TypeScript и обеспечит улучшенную поддержку TypeScript.
Что было изначально в $mol. Даже шаблоны проверяются TS компилятором.
чтобы избежать глобального вмешательства в прототип Vue при установке плагинов. Вместо этого плагины будут применены и привязаны к дереву компонентов.
Что было изначально в $mol. К любому компоненту можно приаттачить набор плагинов и использовать их для расширения функциональности.
Ленивое наблюдение по-умолчанию.
Что было изначально в $mol. Более того, ленивое не только наблюдение, но и все вычисления, позволяя, например, не загружать данные, которые не нужны для рендеринга в текущий момент.
Меньше: новая кодовая база спроектирована с нуля как tree-shaking friendly.
Что было изначально в $mol. Более того, вместо того, чтобы подключать пакет, а потом вырезать лишнее с помощью tree-shaking, в $mol лишний код не подключается изначально. А всё потому, зависимостями управляет автоматика, а не вручную.
рендеринг поддерева в другой части DOM, а не внутри компонента
Что было изначально в $mol. Без всяких порталов можно любой компонент отрендерить в любом другом или вообще в стороне от приложения. Вся фишка в том, что компоненты в $mol — самодостаточные, не зависящие от окружения. Любой компонент может быть приложением, а любое приложение — компонентом.
все слоты, созданные с помощью компилятора, теперь являются функциями и вызываются во время вызова рендеринга дочернего компонента.
Что было изначально в $mol. Более того, тот же принцип действует в любых направлениях. Например, часть родителя может быть функцией от свойств детей, что активно применяется для ленивого рендеринга.
Размер новой runtime библиотеки <10kb в gzip.
Что было изначально в $mol. Точнее не так, как такового рантайма в $mol нет, просто в бандл попадают те модули, которыми воспользовались. Но реактивный "привет мир" как раз 10кб и занимает.
Так что использовать $mol становится всё меньше и меньше поводов, что является весьма позитивной тенденцией.
Мне кажется вам надо менять или метод продвижения или стиль общения. Не знаю что вам поможет. Но, чисто подсознательно, я уже не выберу мол как бы он ни был хорош. Только если что-то меня заставит.
Что было изначально в $mol. Более того, тот же принцип действует в любых направлениях. Например, часть родителя может быть функцией от свойств детей, что активно применяется для ленивого рендеринга.
Ухты! Выглядит, как необычный способ выстрелить себе в ногу, но, не смотря на это, интересно, как это реализовано. Выходит так, что
— свойства детей могут быть изменены не только родительским компонентом (если нет, то почему бы родителю просто не опираться на эти свойства, которые он и прокидывает детям)?
— родительский компонент как-то подписывается на свойства детей?
Или как-то иначе?
И ещё вопрос: детектится ли как-то при этом зацикливание? Например, когда родитель, реагируя на изменение свойства ребёнка, меняет его другое свойство, а ребёнок отрабатывает это изменение и меняет первое свойство, на которое опять реагирует родитель, и так до бесконечности.
Да, данные могут приходить разными окольными путями. Но я говорил про кейс, когда родителю нужны компоненты их детей. Например, возьмём диаграммы. В компонент диаграммы передаётся список графиков. Диаграмма узнаёт у них диапазоны по горизонтали и вертикали, вычисляет общий диапазон и позиционирует графики так, чтобы все влезли. Потом у каждого графика запрашивает превьюшку и название и рендерит легенду внизу с соответствующими превьюшками и названиями. И разумеется, если график решит изменить свой цвет, название или ещё что, то легенда отразит это изменение.
Компоненты — просто классы со свойствами, а свойства уже автоматически трекают зависимости друг между другом благодаря ОРП. В VueJS тоже свойства через орп синхронизируются, но оно гвоздями прибито к компонентам.
Состояния организуются как функции от других состояний. Реактивные циклические зависимости, конечно же, детектятся и приводят к исключениям.
Дмитрий, вас то кто заставил заниматься $mol?
Просто я мазохист. Люблю боль и страдания. А $mol доставляет мне их максимальное количество на единицу кода.
Я ни разу не использовал $mol но думаю что он хорош.
Ну зачем вы обманываете себя? Попробуйте использовать и сразу поймёте, что у него непонятные шаблоны, все компоненты кривые, все демки тормозят, а документации так вообще нет.
Точно лучше Angular и React, но уже не лучше Vue
Если бы $mol был лучше, чем Angular или даже, прости господи, React, то звёздочек у него было бы куда больше, чем у них. Однако у $mol звёздочек в 1000 раз меньше! Выводы, думаю, очевидны.
Я также думаю, что если бы в основе лежал jsonnet он был бы всё ещё лучше
Это же просто генератор json-а. При чём тут фреймворки? Этим jsonnet-ом можно для любого фреймворка данные подготовить.
идеи заложенные в архитектуре $mol на мой взгляд исчерпаны
Да какая там архитектура? Просто навалили в корень репозитория кучу модулей без какой-либо группировки лишь бы их имена в глобальном (!) скоупе были короткими. Это ж надо было додуматься в 2k18 использовать неймспейсы вместо нативных модулей.
Планы на следующую версию Vue.js