Как стать автором
Обновить

Комментарии 31

Я считаю, что в подвале можно использовать массив элементов, состоящий из названия ( иконки ) и ссылки ( функции ) и map'ил бы этот массив выводя все элементы в подвал, если количество элементов большое и не все могут уместиться в ширину подвала, последний элемент был бы выдающий список.

Но это же очень частный случай и далеко не для всех случаев подходит.

>Что такое панель? Это довольно простой компонент, разбивающий видимую область на 2-3 блока

Почему 2-3? А если больше, то это уже не панель? А разве панель служит не для группировки блоков/элементов в себе как контейнере?

Попробуете дать определение по лучше?

Уже дал, комментарий выше.

Оно на столько общее, что под него подпадает чуть ли не любой компонент.

Да, но это так и есть. А то что панель должна что-то разбивать, это вы уже сами придумали.

Ок, я сам это придумал, ввёл определение, и далее его использую. Можете заменить везде в статье слово "панель", на "вуферат", если под "панелью" вы привыкли понимать что-то другое. Суть ведь не в том, что называть панелью, а как реализовать описанный часто используемый компонент.

Вопрос конечно off-topic, но почему в вашем замечательном мегафреймворке вместо нормального слова children используется кривое неграмотное childs?
Странное единообразие. Children это устоявшееся название, используемое чуть ли не во всех фреймворках, любой программист без труда может понять что это. Зато коллегам носителям языка ваш стиль будет корежить взгляд. Имхо, вы слишком ударяетесь в крайности.

Носителей языка куда меньше, чем не носителей. А неносителям куда проще образовывать коллекции добавлением 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="О, да!"
/>

Боюсь вы невнимательно читали. Ваше решение:


  1. Не позволяет удалить футер.
  2. Не позволяет заменить целиком шапку (а не только её содержимое).
  3. Не позволяет дополнительно стилизовать панель в конкретном месте использования.

Впрочем, спасибо за подсказку, как можно упростить код "велосипеда". Изменил в статье на реализацию в 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

Это во первых не кроссбраузерно, а во вторых в вебките стилизованный таким образом скроллбар люто тормозит.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории