Здравствуйте, меня зовут Дмитрий Карловский и я.. дуб. Я пустил свои корни в адептов святого $mol, и выращиваю из них сверх‑людей, способных каждый год сбрасывать былые привычки и убеждения, но тут же пускать побеги свежих идей, базирующихся на прочном рациональном основании.
А в качестве примера, позвольте посеять и в вас зерно сомнения в правильности традиционных решений, и показать, почему синтаксис языка композиции компонент в $mol такой странный, и почему другие языки для этой задачи совсем не подходят.
Требования
Компактность. Чем больше кода, тем больше времени тратится на его поддержку, больше точек отказа, сложнее ориентироваться.
Наглядность. Синтаксис должен недвусмысленно говорить о том, что происходит. По возможности в мозгу должны вырабатываться мнемоники. Иерархия расположения и направления потоков данных должны считываться визуально.
Простота. Чем меньше правил и исключений из них, тем проще и быстрее освоить сам язык и поддерживать для него тулинг.
Сложные свойства. Любое свойство может содержать любые JSON данные вперемешку с объектами и различными привязками свойств.
Локализация. Локализуемые текстовые значения выносятся в файлы локализации и заменяются на ключи. А нелокализуемые остаются в коде как есть.
-
Связывания свойств. Подконтрольные компоненты через свойства связываются с владельцем. Виды связей:
Хаки — настройка подконтрольного объекта.
Алиасы — делегирование свойства подконтрольному объекту.
Контроль мутабельности. Мутабельные свойства допускают изменение значения, но могут их игнорировать. Иммутабельные не допускают изменение значения в принципе.
Ленивые реестры. Свойства могут работать не только с одним единственным значением, но и с разными в зависимости от переданного ключа.
Декларативность. Необходима для стат анализа кода компонент: трансляция в исполняемый код, экстракция локализованных строк, автоматическое формирование конфигуратора и тд.
Типизация. Тайпскрипт должен получать максимум информации о типах, чтобы проверить корректность использования компонент.
Эффективность. pull семантика, минимум телодвижений в рантайме для сборки дерева компонент и обмена значениями между компонентами.
Инверсия контроля. Обилие точек расширения, слотов, параметров. Возможность детально настроить поведение, компоновку и визуализацию компонента из вне. Управление поддеревом компонент через контексты.
Варианты языков
❌
view.ts
— исполняемые классы компонент со статической типизацией❌
view.xjs
— JavaScript с вымышленным расширением для инлайн объявлений методов.❌
view.jsx
— JavaScript расширенный XML синтаксисом.❌
view.html
— мимикрия под языки HTML‑шаблонов.❌
view.json
— декларативная JSON структура✅
view.tree
— DSL основанный на формате Tree.
view.ts
❌ Очень много нетривиального кода.
❌ Плоская структура, потеряна иерархия расположения.
❌ Сложный и медленный статический анализ.
✅ Не требует дополнительных трансляторов помимо TypeScript.
✅ Наглядно видно исполняемый код.
✅ Высочайшая гибкость.
✅ Отличная поддержка всеми IDE.
export class $my_app extends $mol_page {
override head() {
return [
... super.head(),
this.Filter(),
this.Add(),
]
}
override body() {
return [ this.Task_rows() ]
}
@ $mol_mem
filter( next = '' ) {
return next
}
@ $mol_mem
Filter() {
return this.$.$mol_string.make({
hint: ()=> this.$.$mol_locale.text( '$my_app_Filter_hint' ),
value: ( next?: string )=> this.filter( next )
})
}
add_allowed() {
return false
}
add( next: Event ) {
return null
}
@ $mol_mem
Add() {
return this.$.$mol_button_major.make({
title: ()=> this.$.$mol_locale.text( '$my_app_Add_title' ),
enabled: ()=> this.add_allowed(),
click: ( next: Event )=> this.add( next )
})
}
@ $mol_mem_key
Task( id: string ) {
return this.$.$my_task.make({})
}
task_drop( id: string, next: Event ) {
return null
}
@ $mol_mem_key
Task_row( id: string ) {
return this.$.$my_task_row.make({
Task: ()=> this.Task( id ),
drop: ( next: Event )=> this.task_drop( id, next )
})
}
task_rows(): readonly $my_task_row[] {
return [ this.Task_row(id) ]
}
@ $mol_mem
Task_rows() {
return this.$.$mol_list.make({
rows: ()=> this.task_rows(),
})
}
}
export class $my_task_row extends $mol_row {
override title( next?: string ) {
return this.Task().title( next )
}
@ $mol_mem
Task() {
return this.$.$my_task.make({})
}
override sub() {
return [
this.Title(),
this.Drop(),
]
}
@ $mol_mem
Title() {
return this.$.$mol_string.make({
value: ( next?: string )=> this.title( next )
})
}
drop( next: Event ) {
return null
}
@ $mol_mem
Drop() {
return this.$.$mol_button_minor.make({
title: ()=> this.$.$mol_locale.text( '$my_task_row_Drop_title' ),
click: ( next?: string )=> this.drop( next )
})
}
}
view.xjs
❌ Много нетривиального кода.
❌ Сложный и медленный статический анализ.
❌ Изменённая семантика некоторых конструкций языка.
❌ Полное отсутствие тулинга и поддержки IDE.
✅ Высочайшая гибкость.
✅ Наглядная иерархия расположения.
✅ Легко изучается, если разработчик уже владеет JavaScript.
export class $my_app extends $mol_page {
head() {
return [
... super.head(),
this.Filter() = this.$.$mol_string.make({
hint: ()=> this.$.$mol_locale.text( '$my_app_Filter_hint' ),
value: ( next?: string )=> this.filter( next ) = '',
}),
this.Add() = this.$.$mol_button_major.make({
title: ()=> this.$.$mol_locale.text( '$my_app_Add_title' ),
enabled: ()=> this.add_allowed() = false,
click: ( next: Event )=> this.add( next ) = null,
}),
]
}
body() {
return [
this.Task_ros() = this.$.$mol_list.make({
rows: ()=> this.task_rows() = [
this.Task_row( id = '0' ) = this.$.$my_task_row.make({
Task: ()=> this.Task( id ) = this.$.$my_task_row.make({}),
drop: ( next: Event )=> this.task_drop( id, next ) = null,
}),
] as readonly $my_task_row[],
}),
]
}
}
export class $my_task_row extends $mol_row {
@ $mol_mem
Task() {
return this.$.$my_task.make({})
}
sub() {
return [
this.Title() = this.$.$mol_string.make({
value: ( next?: string )=> this.title( next ) = this.Task().title( next ),
}),
this.Drop() = this.$.$mol_button_minor.make({
title: ()=> this.$.$mol_locale.text( '$my_task_row_Drop_title' ),
click: ( next?: string )=> this.drop( next ) = null,
}),
]
}
}
view.jsx
❌ Очень много нетривиального кода.
❌ Плоская структура, потеряна иерархия расположения.
❌ Сложный и медленный статический анализ.
❌ Слабая поддержка IDE самого языка композиции.
export const $my_app = $mol_page.extends( ({
$mol_page,
$mol_string,
$mol_button_major,
$mol_list,
$mol_mem,
$mol_mem_key,
$mol_locale,
$my_task_row,
}, {
head: _head,
}, {
head = ()=> [
... _head(),
<Filter/>,
<Add/>,
],
body = ()=> <>
<Task_rows/>
</>,
filter = $mol_mem( ( next = '' )=> next ),
Filter = $mol_mem( ()=> <$mol_string
hint={ ()=> $mol_locale( '$my_app_Filter_hint' ) }
value={ ( next: string )=> filter( next ) }
/> ),
add_allowed = ()=> false,
add = ( next: Event )=> null,
Add = $mol_mem( ()=> <$mol_button_major
title={ ()=> $mol_locale( '$my_app_Add_title' ) }
enabled={ ()=> add_allowed() }
click={ ( next: Event )=> add( next ) }
/> ),
Task = $mol_mem_key( ( id: string )=> <$my_task/> ),
task_drop = ( id: string, next: Event )=> null,
Task_row = $mol_mem_key( ( id: string )=> <$my_task_row
Task={ ()=> Task( id ) }
drop={ ( next: Event )=> task_drop( id, next ) }
/> ),
task_rows = ()=> [
<Task_row key={"0"} />,
] as readonly ReturnType< typeof $my_task_row >[],
Task_rows = $mol_mem( ()=> <$mol_list
rows={ ()=> task_rows() }
/> ),
})=> <$mol_page {...{ head, body }} /> )
export const $my_task_row = $mol_row.extends( ({
$mol_string,
$mol_button_minor,
$mol_row,
$mol_mem,
$mol_locale,
}, {
}, {
Task: { title } = $mol_mem( ()=> <$my_task/> ),
sub = ()=> [
<Title/>,
<Drop/>
],
Title = $mol_mem( ()=> <$mol_string
value={ ( next?: string )=> title( next ) }
/> ),
drop = ( next: Event )=> null,
Drop = $mol_mem( ()=> <$mol_button_minor
title={ ()=> $mol_locale( '$my_task_row_Drop_title' ) }
click={ ( next?: string )=> drop( next ) }
/> ),
})=> <$mol_row {...{ title, sub }} /> )
view.html
❌ Много визуально зашумлённого кода.
❌ Даже со всеми наворотами IDE HTML не очень удобно редактировать.
❌ Слабая поддержка IDE самого языка композиции.
❌ Не наглядный и неконсистентный синтаксис.
❌ Привычки и ассоциации с HTML слабо помогают и только путают.
✅ Наглядная иерархия расположения.
✅ Простой парсинг стандартными средствами поддерживающими пользовательские DOCTYPE.
<mol_page id="my_app">
<head list>
<super/>
<mol_string bind="Filter">
<hint locale="Filter tasks or Add one" />
<value bidi="filter_query" string="" />
</mol_string>
<mol_button_major bind="Add">
<title locale="Add this task" />
<enabled bind="add_allowed" boolean="false" />
<click bidi="add" null />
</mol_button_major>
</head>
<body hack>
<mol_list bind="Task_rows">
<rows bind="task_rows" list="my_task_row">
<my_task_row bind="Task_row" key="0">
<Task>
<my_task bind="Task" key />
</Task>
<drop bidi="task_drop" key null />
</my_task_row>
</rows>
</mol_list>
</body>
</mol_page>
<mol_row id="my_task_row">
<my_task bind="Task">
<title alias bidi="title" />
</my_task>
<sub list>
<mol_string bind="Title">
<value bidi="title" />
</mol_string>
<mol_button_minor bind="Drop">
<title locale="Drop" />
<click bidi="drop" null />
</mol_button_minor>
</sub>
</mol_row>
view.json
❌ Очень много визуально зашумлённого кода.
❌ Не наглядный и неконсистентный синтаксис.
❌ Слабая поддержка IDE.
✅ Наглядная иерархия расположения.
✅ Простой парсинг стандартными средствами.
{
"$my_app": {
"_extends": "$mol_page",
"head": {
"_array": null,
"_value": [
{ "_expand": true },
{
"_bind": "Filter",
"_extends": "$mol_string",
"hint": {
"_locale": true,
"_value": "Filter tasks or Add one"
},
"value": {
"_bidi": "filter_query",
"_value": ""
}
},
{
"_bind": "Add",
"_extends": "$mol_button_major",
"title": {
"_locale": true,
"_value": "Add this task"
},
"enabled": {
"_bind": "add_allowed",
"_value": false
},
"click": {
"_bidi": "add",
"_value": null
}
}
]
},
"body": {
"_array": null,
"_value": [
{
"_bind": "Task_rows",
"_extends": "$mol_list",
"rows": {
"_bind": "task_rows",
"_array": "$my_task_row",
"_value": [
{
"_bind": "Task_row",
"_extends": "$my_task_row",
"_key": "0",
"Task": {
"_bind": "Task",
"_extends": "$my_task",
"_key": null
},
"drop": {
"_bidi": "task_drop",
"_key": null,
"_value": null
}
}
]
}
}
]
}
},
"$my_task_row": {
"_extends": "$mol_row",
"Task": {
"_extends": "$my_task",
"title": {
"alias": true,
"_bidi": "title"
}
},
"sub": {
"_array": null,
"_value": [
{
"_bind": "Title",
"_extends": "$mol_string",
"value": {
"_bidi": "title"
}
},
{
"_bind": "Drop",
"_extends": "$mol_button_minor",
"title": {
"_locale": true,
"_value": "Drop"
},
"click": {
"_bidi": "drop",
"_value": null
}
}
]
}
}
}
view.tree
❌ Людям, привыкшим к SGML‑ и C‑подобным языкам может потребоваться привыкание.
❌ Слабая поддержка IDE.
✅ Лаконичный код.
✅ Наглядная иерархия расположения.
✅ Наглядное представление потоков данных.
✅ Простой синтаксис даёт удобную обработку.
$my_app $mol_page
head /
^
<= Filter $mol_string
hint @ \Filter tasks or Add one
value? <=> filter? \
<= Add $mol_button_major
title @ \Add this task
enabled <= add_allowed false
click? <=> add? null
body /
<= Task_rows $mol_list
rows <= task_rows /$my_task_row
<= Task_row* $my_task_row
Task <= Task* $my_task
drop? <=> task_drop*? null
$my_task_row $mol_row
Task $my_task
title? => title?
sub /
<= Title $mol_string
value? <=> title?
<= Drop $mol_button_minor
title @ \Drop
click? <=> drop? null
Этот код транслируется в тот страшный код на TS из начала статьи.
Выводы
Изначально может показаться, что использовать более привычный синтаксис предпочтительнее. Однако, пытаясь впихнуть в него такие штуки, на которые он не был рассчитан, получается даже хуже, чем изобрести новый, заточенный на конкретную задачу, синтаксис, ибо старые привычки бесполезны и только мешают понять новые концепции, для которых старый синтаксис используется не по назначению, вызывая когнитивный диссонанс.
Новый же, консистентный синтаксис, где нет ничего лишнего, но есть всё необходимое, не смотря на свою необычность, изучается куда быстрее даже с нуля, ведь он не тянет за собой атавизмы от прошлых этапов эволюции.
Направления роста
Обсудить эти и другие форматы можно в теме про языки программирования на форуме Гипер Дев.
Помощь в изучении $mol можно найти в теме о $mol там же.
Узнать как за 5 минут сделать свой DSL на базе tree с сорсмапами, подсветкой синтаксиса, подсказками и автодополнением можно из этого выступления на HolyJS.
И, конечно, по любым формам сотрудничества можно написать лично мне. Давайте вместе растить дубовую рощу!
Комментарии (33)
nikfarce
00.00.0000 00:00+5Зачем в хабах ReactJS указывать? Я на этот хаб подписался, чтобы читать статьи о React, а не $mol.
nin-jin Автор
00.00.0000 00:00-10На Хабре почему-то до сих пор нет хаба $mol. Хаба JSX я тоже не нашёл.
nikfarce
00.00.0000 00:00+7Если вы считаете, что на сайте не хватает какого-то хаба, то предложите его через форму обратной связи. В сопроводительном письме укажите не менее 10 ссылок на публикации, которые на данный момент расположены «не там».
Shannon
00.00.0000 00:00+8Прикольно, но первое что я обнаруживаю зайдя по ссылке на подробности про $mol — это горизонтальная прокрутка и обрезанный интерфейс с текстом.
Наверное, это лучшая демонстрация того, что подобно тому, что не каждый размер браузера подходит для приятной работы с $mol, как и то, что $mol не для всех.И убедить тех, кто с удовольствием пользуется json перейти на view.json, это как убедить, что у кого-то не правильный размер браузера и он пользуется ПК не правильно.
Хотя, практика показывает, что если что-то действительно решает существующую проблему, то синтаксис уже не важен. Например, понятно какую проблему решает rust — и его "ужасный" синтаксис в итоге игнорируется. Про $mol так не получается сказать, он не решает какую-то глобальную проблему, он просто предлагает делать тоже самое, но немного по другому.
При чем, игнорируются потребности других, например в синтаксисе нет поддержки однострочников. Ну кому-то зайдет, наверное.nin-jin Автор
00.00.0000 00:00-4Поздравляю, вы нашли баг на сайте. Какое он имеет отношение к теме статьи?
view.tree разделяет декларативную композицию и императивную логику. У этого разделения есть множество приятных бонусов, о которых я рассказывал тут: https://page.hyoo.ru/#!=xl437w_w1mpfo
Один из них - да, сложно наговнокодить, как бы ни хотелось влепить "однострочник" по среди вёрстки.
Shannon
00.00.0000 00:00+3Это же притча. Вроде всё работает как надо, но одна мелочь руинит всё. Плюс, кажется, это не баг, а сайт так сделан, но не суть.
Про view.tree ведь можно сказать и по другому, по аналогии с минусами для других форматов:
- магические символы
- волшебные отступы
- смесь бинарного и текстового формата
- непроглядная мешанина всего подряд
- путаница с unix \ переносом строки
- хорошо совместим с $mol (это плюс)
А так, технически $mol очень крутой, вот эта система атомов, связей, потоков данных и прочее. Но tree не выглядит так, как его пытаются преподнести. Это скорее шаг назад.
flancer
00.00.0000 00:00+1Вот за что мне нравится HTML, так этот за то, что его можно прямо в браузере править. Открываешь панель инструментов по F12 и правь DOM хоть вдоль, хоть поперёк. Более того, все перечисленные форматы, после обработки транспилятором, в браузере будут HTML'ом. Просто потому что. И если будут на странице какие проблемы, то разбираться ты будешь именно с транспилированным HTML'ом. И детранспилировать во всю эту первоначальную экзотику будешь самостоятельно и в голове. Это одна из причин, почему среди всего другого я для себя выбрал vue. Правило наименьшего удивления.
nin-jin Автор
00.00.0000 00:00-3view.tree тоже можно править прямо в браузере. Берёте любое приложение и настраиваете его как хотите. Вот, для примера, дефейс $mol портала. И нет, $mol не формирует HTML, он динамически строит DOM для видимой области.
flancer
00.00.0000 00:00+3Мы немножко по-разному понимаем "панель инструментов по F12":
$mol не формирует HTML, он динамически строит DOM для видимой области.
Значит сам браузер трансформирует DOM в HTML в панели инструментов. Просто потому, что HTML - это стандарт для веба. Как и CSS, как и JavaScript. У вас же нет плагина для браузера, чтобы он транслировал DOM обратно в
tree
, не так ли? Иначе в качестве примера дефейса $mol-портала был бы сделан скриншот панели инструментов, а не дана ссылка на сторонний сайт (studio.hyoo.ru vs. mol.hyoo.ru).Я вполне допускаю, что
tree
гораздо удобнее для представления структуры страницы/маршрута/компонента в силу своей компактности, но... YAML до сих пор не вытеснил JSON, а JSON до сих пор не вытеснил XML. Наверное потому, что не только компактность важна при описании структур данных.nin-jin Автор
00.00.0000 00:00-2Студия ещё молода, не всё умеет, но уже умеет гораздо больше, чем в принципе возможно создать для других фреймворков.
Про YAML/JSON/XML можете почитать тут: https://page.hyoo.ru/#!=8i7ao7_xfyxah
Никаких объективных причин, кроме инертности мышления, использовать их нет.flancer
00.00.0000 00:00+2Студия ещё молода, не всё умеет, но уже умеет гораздо больше, чем в принципе возможно создать для других фреймворков.
"больше, чем в принципе возможно" (y) Как можно относится серьёзно к вашей разработке после таких несерьёзных заявлений? :) Ведь всё, что вы пишете про свой фреймворк, нужно делить на 10 после таких заявлений. Энергии вам, конечно, не занимать, но вот с объективностью - беда-а-а.
Никаких объективных причин, кроме инертности мышления
Тогда у меня для вас хорошая новость, вам осталось преодолеть всего лишь одно препятствие!
nin-jin Автор
00.00.0000 00:00-2Скорее умножать на 10. Я очень сильно скромничаю. Можете сами попробовать реализовать аналог студии для React или для Vue.
flancer
00.00.0000 00:00+3Как я уже отметил в комменте выше - объективность не входит в список ваших достоинств. Иначе бы $mol уже давно подвинул и React, и Vue. Но на Хабре вас любят как раз таки за её отсутствие.
nin-jin Автор
00.00.0000 00:00-1Объективно вы ничего такого сделать не сможете, поэтому даже не будете пытаться, вместо этого предпочитая нападки на личность.
flancer
00.00.0000 00:00+5Объективно я делаю нечто другое. "Такое" делаете вы. Нападки на личность? Пожалуй. Но личность сама дала повод - "уже умеет гораздо больше, чем в принципе возможно создать для других фреймворков"
Для человека-разумного подобная формулировка - просто какой-то зашквар. Но это на мой взгляд, конечно.
yroman
00.00.0000 00:00+1Почитал доку здесь https://page.hyoo.ru/#!=vv2nig_s5zr0f , но всё же не могу понять почему для событий используется именно такой синтаксис:
click? <=> remove? null
Вы не могли бы пояснить?nin-jin Автор
00.00.0000 00:00+2У кнопки есть канал click, в который на пушит события при нажатии. По умолчанию этот канал ничего не делает. При создании кнопки, этот канал поменяется на наш канал remove, чтобы кнопка пушила события к нам. Собственно двусторонняя связь разрешает пушить в канал значения. При одно сторонней - пуши игнорируются. То есть владелец контролирует кто имеет возможность пушить в его каналы.
LyuMih
00.00.0000 00:00Привет!
Заходи к нам в чат https://t.me/mam_mol, ответим на все вопросы)
Если у тебя есть идеи для пет проектов, который ты хотел бы сделать, мы поможем его довести до результат на $mol ^_^ за очень короткий срок.
А так ещё приглашаю поучавствать в опен соурсе с нами. В самом моле - различные студии https://studio.hyoo.ru/ и парсеры https://tree.hyoo.ru/
Или со мной - я сейчас по фану делаю аудиопереводчик view.tree -> человеский язык, который отвечал бы на эти вопросы))
Сайт: https://lyumih.github.io/milis/treesay/storybook/-/#!demo=milis_treesay_demo
и его код https://github.com/Lyumih/milis/tree/main/treesay
LyuMih
00.00.0000 00:00Мне понравился $mol. В свободное от работы (классический финтех на реакте) делаю на нём пет проекты и стараюсь наладить документацию и взаимодействие с людьми).
Недавно захотел проверить MVP 2 моих спонтанных идей, вот один из них.
1. Проект "Сказка в лесу" - чтобы по QR на фигуре в парке можно было перейти на сайт и получить информацию по герою сказке, а также послушать аудиверсию, посмотреть сказку на ютуб и почитать прям в лесу.
Получилось вот так: https://lyumih.github.io/milis/skazka/-/#!skazka=heroes/heroes=vasilisa и репозиторий с проектом https://github.com/Lyumih/milis/tree/main/skazka из 3 файлов (весь сайт).
41 строка view.tree и 74 строк view.ts - из которых 17 строк - заглушка JSON на тот момент.
Ещё $mol очень интересен как российский опен соурс проект - давно хотел поучавствовать в подобной разработке, но в больших американских react/vuev/angular проектах не нашёл, чтобы улучшить без гемморая. А тут всё понятно - компоненты минимальные и общение всё идёт на русском языке
gohrytt
Главная проблема данной библиотеки всё ещё в том, что есть устоявшиеся синтаксические основы языков программирования которые позволяют после любого одного языка программирования быстро разбираться в основах любого другого. И никто не будет прикладывать усилия к тому, чтобы понять гениальные идеи авторов библиотеки, скрытые за непонятным и недружелюбным синтаксисом.
Простой синтаксис даёт удобную обработку...
, окей, давайте попробуем:Вот честно, я ни разу в жизни не ел грибы, но кажется если я их употреблю и сяду программировать - напишу что-то подобное.
shasoftX
Собственно поэтому автор и пытается достучаться до разработчиков, демонстрируя выгоду от перехода на свой синтаксис.
Нужна критическая масса разработчиков, которые на этом пишут чтобы это пошло в массы.
gohrytt
Автор не демонстрирует выгоду, да и критическая масса тут не поможет. Проблема в том что вот допустим я новичок и хочу сделать сайт. Когда я учу $mol я учу только $mol. Когда я учу react я учу ещё и vue и angular и svelte и ещё 100500 разных фреймворков.
shasoftX
Когда вы новичек, то вас такие проблемы вообще не волнуют. Вы просто учитесь писать сайт.
gohrytt
Если новичков такие проблемы не волнуют, почему никто не учит лисп?
shasoftX
Потому что трудной найти инструкцию как написать сайт на лиспе.
nin-jin Автор
nin-jin Автор
Когда вы учите React, вы учите только React. На Vue, Angular, Svelte приложения строятся совсем по другому. А вот когда вы учите $mol вы учите прежде всего TS, который понадобится вам в любом более-менее серьёзном проекте.
Кроме того, изучение $mol даёт хорошую научную базу и прививает чутьё к лучшим архитектурным практикам, что опять же пригодится далеко за пределами $mol.
nin-jin Автор
В статье есть ссылка, по которой вы найдёте ответы на все ваши вопросы. Обратите также внимание, что большая часть из них у вас возникла бы с любым синтаксисом.
LyuMih
Постараюсь ответит на вопросы в комментари.
Синтаксис действительно просто и состоит из нескольких знаков, который выполняют всем нам привычные действия. Умещается весь синтаксис +- 1 строку.
$это_компонент -комментарий, \строка, * объект его_свойство ^и_перегрузка_свойства, /массив
А дальше уже поинтереснее
@ \автоматическа локализация строки, <= <=> => наглядное связывание свойства (реактивность), Task_row* - перебераем массив с компонентами и ? - динамическое свойство
Кто прочитал данный комментарий - поздравляю, вы освоили весь view.tree!
Главное тут скорость и эффективность - 1 символ на 1 любое действие. Не 1 лишниго символа нет в view.tree
Вот тут есть шпаргалка https://mol.hyoo.ru/#!section=docs/=vv2nig_s5zr0f/Docs.View"vv2nig_s5zr0f".Details=Шпаргалка по спецсимволам и площадка, где можно поиграться с view.tree https://mol.hyoo.ru/#!section=view.tree
nin-jin Автор
Так будет правильнее:
* ключ значение
^ наследование значения от родителя
Task_row* зависимость значения от ключа
? изменяемое свойство
jtjag
Тем не менее вы не можете зная Pascal перейти к работе на JS. Если вы про такие вещи как операторы, переменные и т.п. то во view.tree всё это есть...
Все мы прикладываем усилия что бы понять новый для нас инструмент. Для того что бы научиться делать хорошие приложения на react как ни крути придётся почитать документацию.
Дело в том что синтаксис простой, а не интуитивный. После внимательного прочтения документации и попытки реализовать какой то базовый компонент вы поймете почему view.tree прост.
Если вам действительно интересно вы можете уделить немного времени документации, а непонятные моменты уточнить в чате тг https://t.me/mam_mol. Лично я был удивлен оперативностью отклика сообщества
Удачи!
gohrytt
Если что я уделил, мне нравится $mol) Просто его пиар кажется несколько наивным