Comments 44
Для сравнения, полный код приложения с прогнозом погоды на $mol:
/my/weather/weather.view.tree
$my_weather $mol_page
title \Weatcher app
api_base \http://weather.example.org/
body /
<= City $mol_string
hint \City name
value?val <=> city?val \
<= Forecast $mol_view
sub /
\Forecast:
<= forecast \
/my/weather/weather.view.ts
namespace $.$mol {
export $my_weather extends $.$my_weather {
forecast() {
const uri = new URL( this.api_base() )
uri.searchParams.set( 'city' , this.city() )
return $mol_http.resource( uri.toString() ).json().forecast
}
}
}
/my/weather/weather.view.tree
Если смотреть это с точки зрения читаемости, то выглядит оно не очень
Какие мы нежные :-) А конкретней, что не так?
Боги, да все не так. Вам уже пол года, если не больше, об этом говорят.
Кроме аргумента "я не хочу ничего изучать, я хочу бац-бац и в продакшен, а после меня хоть потоп" я ничего за пол года так и не услышал. Может я что-то пропустил?
Ну просто мы неправильные пчелы.
А если серьезно, изучать что-то должно нравиться, либо под дулом заказчика. Так как $mol не про второе, то остается только первое, но ваши шаблоны не вызывают чувства эйфории. Вы их разработали, вам с ними хорошо и просто, а мне (как и остальным) — нет. Попробуйте поменять синтаксис на что-нибудь более… спокойное, возможно как плагин к парсеру.
Кроме того, крайне большим шагом к адаптации станет плагинчик-хайлайтер к тому же vscode/atom, чтобы не нужно было ломать глаза среди забора торчащих в разные стороны слэшей и стрелок.
Для Атома есть. Правда ставить его сейчас приходится через клонирование репозитория :-(
Ещё есть плагин для WebStorm, но в репозитории он для старой версии Tree. К сожалению JetBrains что-то сломали и новые билды плагина не хотят работать.
ваши шаблоны
Какие ещё шаблоны? У нас нет никаких шаблонов. Всё, что у нас есть — это компоненты и описание их коммуникаций.
Попробуйте поменять синтаксис на что-нибудь более… спокойное
"Спокойное" — это как? Вот тут я пробовал описывать одно и то же в форматах Tree, XML, JSON. Какой вариант вам больше по душе?
Какие ещё шаблоны? У нас нет никаких шаблонов. Всё, что у нас есть — это компоненты и описание их коммуникаций.
Называйте, как хотите. Представление у вас живет отдельно от логики.
Вот тут я пробовал описывать одно и то же в форматах Tree, XML, JSON.
Ну так а почему вы об этом не говорите никогда? Вот слушал я вас на РИТ++ — ни слова, даже вопрос вам задали, а где разметка то?
Явно меньше углов для перехода у html-подобного варианта. Именно поэтому JSX такой популярный, в отличие от формата, используемого в elm/purescript (обычные функции).
Называйте, как хотите. Представление у вас живет отдельно от логики.
Структура живёт отдельно от логики, а вместе со стилями они образуют представление.
Ну так а почему вы об этом не говорите никогда? Вот слушал я вас на РИТ++ — ни слова, даже вопрос вам задали, а где разметка то?
Так доклад про реактивное программирование, а не про разметку был :-)
Явно меньше углов для перехода у html-подобного варианта. Именно поэтому JSX такой популярный, в отличие от формата, используемого в elm/purescript (обычные функции).
Только вот во view.html ещё сложнее разобраться, чем во view.tree, так как используемые идиомы очень криво ложатся на html. Можно отказаться от идиом, но тогда получится ещё один клон Ангуляра — зачем оно надо?
Так доклад про реактивное программирование, а не про разметку был :-)
Неправда, доклад был про $mol, хоть и назывался по-другому :)
Только вот во view.html ещё сложнее разобраться
Ну не знаю, мне все стало кристально ясно. Но писать везде bind тоже не очень. Но я уверен, что все-равно можно накрутить html-подобный DSL с удобным неявным связыванием.
Неправда, доклад был про $mol, хоть и назывался по-другому :)
Примеры были на $mol_mem, а доклад был про ОРП и бонусы, которые он даёт. Половину этих бонусов вы можете получить с MobX, например.
Ну не знаю, мне все стало кристально ясно. Но писать везде bind тоже не очень. Но я уверен, что все-равно можно накрутить html-подобный DSL с удобным неявным связыванием.
Не знаю, что там вам стало "кристально ясно", но суть bind вы так и не поняли :-) Суть его в том, что у каждого элемента (как и у любого другого свойства компонента) должно быть уникальное имя, по которому к нему можно обратиться. И имя это может быть задано только программистом вручную.
Примеры были на $mol_mem, а доклад был про ОРП и бонусы, которые он даёт. Половину этих бонусов вы можете получить с MobX, например.
Может, тогда не стоило приводить примеры на $mol? Потому что проблема не в "ОРП", а в нем.
Суть его в том, что у каждого элемента (как и у любого другого свойства компонента) должно быть уникальное имя, по которому к нему можно обратиться. И имя это может быть задано только программистом вручную.
Ну значит у вас кривые примеры. Если это не bind в привычном понимании (связывания значения элемента представления со значением поля модели), но поправьте доки. Понять, что это такое из примера в виде .tree вообще невозможно. С доками кстати тоже большая беда, да, много всего, но что с этим делать — не понятно ну вот совсем.
Может, тогда не стоило приводить примеры на $mol? Потому что проблема не в "ОРП", а в нем.
Какая проблема?
Ну значит у вас кривые примеры. Если это не bind в привычном понимании (связывания значения элемента представления со значением поля модели), но поправьте доки.
Да нет, это bind. Просто значением является вложенный компонент. Это очень мощная идиома, позволяющая динамически отрендерить что угодно во что угодно. Без плясок с бубном как в Ангуляре и не ломая переиспользование узлов, как в Реакте.
Какая проблема?
Жуткий синтаксис и отсутствие хорошей документации с хорошими примерами.
Да нет, это bind. Просто значением является вложенный компонент. Это очень мощная идиома, позволяющая динамически отрендерить что угодно во что угодно. Без плясок с бубном как в Ангуляре и не ломая переиспользование узлов, как в Реакте.
Мне кажется, что стоит написать статейку разжевывающую именно этот момент. Потому что в Реакте я делаю
const Wrapper = ({Child}) => (
<div>
Hi, <Child/>
</div>
);
и прекрасно себя чувствую...
Жуткий синтаксис и отсутствие хорошей документации с хорошими примерами.
В моём докладе не было ничего про "жуткий синтаксис".
Потому что в Реакте я делаю и прекрасно себя чувствую...
А стилизуете/локализуете вы это дело как?
l10n/i18n через react-intl
Стилизация/темизация через те же HOC/HOF и react-css-themr
Ладно, тут Wrike уже жалуется на оффтоп
О том и речь, что такой простой код у вас только в комментариях на Хабре, а в реальном проекте он неизбежно обрастает костылями:
import React, { Component } from 'react';
import { themr } from 'react-css-themr';
import { FormattedMessage } from 'react-intl'
import { SuccessIcon } from 'icons';
import successTheme from './SuccessButton.css';
@themr('MySuccessButton', successTheme)
class Button extends Component {
render() {
const { theme, icon, title } = this.props;
return (
<button className={theme.button} >
{ icon || <SuccessIcon /> }
<span className={theme.text} >{ title || <FormattedMessage id='SuccessButton.title' /> }</span>
</button>
)
}
}
export default Button;
.button {
padding: .5rem;
}
.text {
margin-left: .5rem;
}
На "жутком синтаксисе" всё куда проще:
$my_button_success $mol_button
sub /
<= Icon $mol_icon_success
<= Text $mol_view
sub /
<= title @ \Success
[my_button_success] {
padding: .5rem;
}
[my_button_success_text] {
margin-left: .5rem;
}
Где костыли-то? То, что вы называете "костылями", на деле является инкапсуляцией стилей и управлением зависимостями через css-модули, чего, судя по всему, ваш $mol лишен.
В любом случае, вы теряете нить обсуждения, так как мой изначальный посыл был про документацию вашего $mol и кривейший синтаксис. А "костыли в реакте" мне как-то по сотому разу обсуждать не охота.
Где костыли-то?
Костыли в куче копипасты, из-за которого "простой шаблон на реакте" становится совсем не простым по мере приближения к продакшену.
инкапсуляцией стилей и управлением зависимостями
Ну и какая польза от параноидальной инкапсуляции и ручного управления зависимостями?
css-модули, чего, судя по всему, ваш $mol лишен.
В $mol нет css-модулей или js-моделей. Есть просто "модули", внутри которых код может быть на самых разнообразных языках и все действуют по одним и тем же правилам.
изначальный посыл был про документацию вашего $mol и кривейший синтаксис
А давайте по существу? Чего конкретно вы не смогли найти в документации? И в чём именно кривизна синтаксиса? Я бы с радостью восполнил пробелы и улучшил синтаксис.
Синтаксис вообще незнакомый. Если у ng всё же ближе к html, у JSX тоже как-то входит стандартный код для шаблонизаторов, то тут вообще новое. Нету ассоциаций с привычными вещами. Тут нужно с нуля по факту учить синтаксис. Я именно из-за привычности в своё время выбрал Pug (ранее haml) вместо Slime.
pug очень похож на html?
Он похож на не совсем стандартный CSS, но похож, а tree просто изобилует разными спец символами и нет ничего похожего на теги, css-классы или атрибуты.
Поэтому без глубокого погружения невозможно оценить на сколько лучше стало или как хоть это сопоставить с кодом на другом FW.
Напишите же в конце концов статью, где будет описан процесс создания простой «Кнопки» с нуля, без использования уже готовых $mol_*
-компонентов.
Главное, в этом примере должно быть не просто «вот так делается кнопка», а «раньше вы писали вот такой HTML», а «теперь вам достаточно всего вот такой записи».
Затем показать, как добавить такой кнопки title/disabled
, кастомные атрибуты, запихать внутрь текст + иконку и сделать возможность, чтобы при передаче href
свойства, кнопка использовала тег a
, вместо button
.
Финальный шаг, как интегрировать эту кнопку в уже готовое приложение не на $mol
.
P.S. В конце можете написать, что ничего этого делать не надо, 99% компонентов уже имеют стандартную реализацию, например вот Кнопка.
А вы всё со своим $mol всё бегаете… Заканчивайте уже, только вы его рекламируете, а не он себя.
А почему вы сравниваете React Native с Ionic'ом, а не с Native Script'ом?
Бешеные псы: Angular 2 vs React: доклад Евгения Гусева и Ильи Таратухина