Комментарии 31
Почему 2-3? А если больше, то это уже не панель? А разве панель служит не для группировки блоков/элементов в себе как контейнере?
Попробуете дать определение по лучше?
Оно на столько общее, что под него подпадает чуть ли не любой компонент.
Носителей языка куда меньше, чем не носителей. А неносителям куда проще образовывать коллекции добавлением s в конце, чем ковыряться в словаре каждый раз. Можете считать это вариантом венгерской нотации. Да, а ещё эта запись короче, что важно, для часто используемого термина.
В ней намеренно не используются хитрые обороты, чтобы автоматический переводчик мог перевести её наиболее адекватно.
Автоматический переводчик не может перевести что-либо адекватно, кроме односложных фраз, типа "Насколько хладен ваш чай?"
Вообще не понятна мне эта реклама вашего $mol. Вот честно. Если он так хорош, что даже лучше чем React, то наверное он сам найдёт свою аудиторию, зачем на себя наводить неприязнь людей, записывая статьи в профильных хаб?
Никто не говорит, что он переводит идеально. А вы что предлагаете? Делать вид, что проблемы понимания документации на не родном языке не существует?
Данная статья о JSX, его проблемах и путях их решения. Было бы странно не поместить её в профильный хаб.
Наиболее адекватное решение проблем JSX, на мой взгляд — использование языка view.tree. При желании, вы можете прикрутить его к React или любому другому компонентному фреймворку. Я же показал его преимущества на примере готовой реализации в $mol.
Давайте лучше поговорим о том, почему у вас вызывает неприязнь критика какого-то языка. Вы считаете JSX идеальным, а React непогрешимым? Вы не хотите, чтобы используемый вами инструмент улучшался, беря лучшие идеи у конкурентов? Вы боитесь, что через пару лет в моде будут совершенно другие решения и снова придётся переучиваться и переписывать свой код?
Мне не нравится, что вы слишком быстро приравняли React и $mol. Через 3 года уже будут совершенно другие технологии, и реакт, и анугляр, и ваш $mol загнуться. Но при этом надо не забывать, что React — библиотека, а ваша реализация больше похожа на что-то типа куска фреймворка (я это я про .tree и его реализацию).
На счёт неудобности записи JSX… Ну тут у каждого свои мозги, мне Emmet'а хватает. Пишу себе Panel>Header^Body^Footer
, нажимаю tab и получаю нормальный такой JSX.
Кстати, что за рвение такое смешивать верстальщиков с дизайнерами? Не понимаю. Если это на такие ситуации, когда дизайнер даёт слишком мудрёные шаблоны и верстальщик говорит: "Раз такой умный, сам и сделай!" Тогда это бредовая идея. Дизайнер должен знать, что выполнимо, а что нет. Иначе получается гибрид, которые не умеет делать ни то, ни другое. Обычно это какой-нибудь птушник, который закончил курс "дизайнеров одежды" и "оператор эвм" и тупо знает где в винде находится командная строка.
В общем, слишком рано вы начинаете свои восхваления.
$mol — фреймворк.
$mol_viewer — библиотека, реализующая рендеринг компонент. Аналог React + TypeScript.
view.tree — декларативный DSL для описания компонент. Аналог TSX.
Даже если, через 3 года придёт понимание, что так рендерить нельзя, то появится какой-нибудь $mol_viewer2, реализующий новый подход, всё остальное останется на месте.
На счёт неудобности записи JSX…
Я говорил про неудобство чтения. Неудобство записи — следствие из неудобства чтения. И приведённные вами костыли (emmet), как раз подтверждают, что проблема есть и она беспокоит многих. Во view.tree такой проблемы нет изначально и подобные костыли не нужны.
Кстати, что за рвение такое смешивать верстальщиков с дизайнерами?
А это вы откуда взяли? Вы точно вкладку не перепутали?
Венгерская нотация уже давно умерла (с появлением нормальных IDE), да и то, что вы тут описываете — не венгерская нотация.
Все указанные вами библиотеки обладают большей функциональностью, чем просто панель. Неудивительно, что они содержат больше кода.
Вот эквивалентное вашему решение (7 строк):
function Panel({head, body, footer}) {
return <div className="panel">
<div className="panel-head">{head}</div>
<div className="panel-body">{body}</div>
<div className="panel-footer">{footer}</div>
</div>;
}
//использование
<Panel
head={<div><h1>Привет, мир!</h1><button>Закрыть</button></div>}
body="Ты прекрасен!"
footer="О, да!"
/>
Боюсь вы невнимательно читали. Ваше решение:
- Не позволяет удалить футер.
- Не позволяет заменить целиком шапку (а не только её содержимое).
- Не позволяет дополнительно стилизовать панель в конкретном месте использования.
Впрочем, спасибо за подсказку, как можно упростить код "велосипеда". Изменил в статье на реализацию в 44 CLOS.
А смысл тогда панели то? Она же должна быть в одном стиле. Если она в другом стиле, то это по идее другой элемент. Короче, тут уже в реализации проблема, а не в JSX.
Должна быть в одном стиле, но при этом должна быть настраиваемой, а не высеченной в граните, из-за чего для малейшего изменения нужно заводить отдельный "высеченный в граните" компонент. К чему это приводит — можете глянуть на сайте Тинькоффа — 3мб в гзипе, чтобы показать одну страницу.
Имя класса для стилизации добавить не сложно. Как и удаляемые блоки. Кода сильно больше не стало:
function Panel({className, head, body, footer}) {
return <div className={classNames('panel', className)}>
{head && <div className="panel-head">{head}</div>}
<div className="panel-body">{body}</div>
{footer <div className="panel-footer">{footer}</div>}
</div>;
}
Пункт 2 про замену шапки я не понимаю. Если вам нужна панель с другой шапкой, возьмите и сделайте другой компонент. Зачем все пихать в единственный?
Отлично, теперь вам нужно добавить панели атрибут role, высоту подвала вам нужно задавать скриптом, а тело должно иметь кроссбраузерно стилизованный скроллбар. Отдельный компонент для каждого случая? Или один компонент, но с парой десятков параметров?
Затем, что нужен точно такой же компонент с точно такими же подкомпонентами, но один из подкомпонент должен быть немного другим.
Атрибут role выставляется внутри панели. Пробрасывать его снаружи только для некоторых панелей – странно.
Вычисляемая высота и кастомный скроллбар можно сделать и без js. Проблемы с высотой сейчас решаются flexbox, а скролббар можно кастомизировать как псевдоэлемент -webkit(-moz)-scrollbar
Пробрасывать его снаружи только для некоторых панелей – странно.
От чего же странно, если в определённом контексте у панели другая семантика?
Проблемы с высотой сейчас решаются flexbox
Я не говорил, что это некая "проблема". Это требование. Например, нам нужно, чтобы высоту можно было менять, двигая по подвалу пальцем.
скролббар можно кастомизировать как псевдоэлемент -webkit(-moz)-scrollbar
Это во первых не кроссбраузерно, а во вторых в вебките стилизованный таким образом скроллбар люто тормозит.
React'ивные Panel'и