Комментарии 49
Программисты, выбирающие технологию по код стайлу, не являются целевой аудиторией.
Вам решать, но хороший код стайл не менее важен чем хорошая архитектура
А с чего вы взяли, что это у нас плохой, а привычный вам — хороший?
это удобно писать? Вместо того, что-бы писать переменную только буквами, вы к ней еще предлагаете $_ или $mol_
что читабельней
$mol_table
или
table?
а если название будет длиннее?
$mol_users_table_for_students_page
или
UsersTableForStudentsPage
Зачем мне эти $/_? $.$$ когда можно обойтись без них?
Можно и без них, только придётся писать в 2 раза больше кода. Тут можете глянуть на примере Реакта: https://github.com/nin-jin/HabHub/issues/6
что читабельней $mol_table или table?
Какой именно table вы имеете ввиду? Я нашёл 6:
$mol_grid_table
$mol_app_report_table
$mol_list_demo_table
$mol_perf_uibench_table
$mol_dev_format_table
$mol_log2_table
$mol_users_table_for_students_page или UsersTableForStudentsPage
Любители верблюдов обычно убеждены сами и пытаются убедить всех окружающих, что второе читать легче. Однако, это не так. Первая форма записи лишена неоднозначностей с аббревиатурами и слова чётко различимы, а не сливаются в единое полотно. Обоснование можете почитать тут: https://github.com/eigenmethod/mol/wiki/PascalCase-camelCase-kebab-case-snake_case
Любители верблюдов обычно убеждены сами и пытаются убедить всех окружающих, что второе читать легче. Однако, это не так. Первая форма записи лишена неоднозначностей с аббревиатурами и слова чётко различимы, а не сливаются в единое полотно. Обоснование можете почитать тут: github.com/eigenmethod/mol/wiki/PascalCase-camelCase-kebab-case-snake_case
По поводу пункта «Проблемы с аббревиатурами: mxBADownload» соглашусь, по поводу остального — нет, когда много кода — camelCase элементарно компактнее и опрятнее смотрится, из-за чего легче воспринимается, а с монохромным шрифтом отлично читается
Какой именно table вы имеете ввиду? Я нашёл 6:
Тот, который импортнули в начале файла
Если вы не написали IDE, которая на ходу переводит все идентификаторы и стандартной и сторонних билиотек JS/TS в snake, вероятно, нам надо читать раздел смешение стилей?
У меня на проекте сейчас реактом и styled-components. То есть, весь CSS описывается на уровне компонента, стили проверяются vscode-styled-components. Может быть и не идеально, но каких-то особенных проблем не доставляет.
А вообще, вы можете сравнить концептуально $mol c каким-то близким фреймворком — он действительно несет что-то новое? Вот автор постоянно постит статьи типа "всего за полчаса я сделал аналог экселя" — там действительно есть какие-то высокоуровневые абстракции которых нет у других или это что-то еще?
И еще. Во фронтенде это принято постоянные префиксы вот такие? Вместо "мама мыла раму" "$mol_мама $mol_рыла $mol_маму"
Нашли пару багов — это ещё не "пользоваться нельзя". Не преувеличивайте.
Если вам, вдруг, интересно, почему так происходит. showcase.hyoo.ru открывает кучу приложений на одном экране. Каждое приложение контролирует свой скролл. И если оно где-либо вызывает scrollIntoView, то скролл происходит не только в нём, но и во внешнем приложении. Вот такие у нас кривые веб-технологии. Скорее всего придётся переделать витрину так, чтобы единомоментно было видно лишь одно приложение.
Попробуйте так же открыть кучу приложений на любом другом фреймворке и браузер просто прибьёт вкладку, после нескольких минут тормозов.
И еще. Во фронтенде это принято постоянные префиксы вот такие? Вместо «мама мыла раму» "$mol_мама $mol_рыла $mol_маму"
Это фишка автора, как раз из-за таких вот фишек фреймворком мало кто пользуется.
можете сравнить концептуально $mol c каким-то близким фреймворком — он действительно несет что-то новое?
Тут я рассказывал про отличительные особенности:
https://github.com/nin-jin/slides/tree/master/mol
https://github.com/nin-jin/HabHub/issues/23
там действительно есть какие-то высокоуровневые абстракции которых нет у других или это что-то еще?
Простые ортогональные абстракции, позволяющие минимумом кода сделать многое. Экосистема готовых компактных компонент, которые легко переиспользуются и кастомизируются под контекст. Отсутствие пропасти между созданием переиспользуемых компонент и специфичных.
Во фронтенде это принято постоянные префиксы вот такие? Вместо "мама мыла раму" "$mol_мама $mol_рыла $mol_маму"
Не принято. Обоснование тут: https://github.com/eigenmethod/mol/wiki/Fully-Qualified-Names-vs-Imports
Не принято. Обоснование тут: github.com/eigenmethod/mol/wiki/Fully-Qualified-Names-vs-Imports
все эти плюсы переплюнет автоимпорт от любой нормальной ide
в итоге минусы остаются, а именно: длинные имена которые нужно писать каждый раз, вместо импорта вверху файла который делается автоматом и скрыт от глаз по умолчанию
Если есть конфликт имен — в импорте можно сделать {user as molUser}, но такое бывает очень редко
все эти плюсы переплюнет автоимпорт от любой нормальной ide
Автоимпорт не отработает для ещё не скачанного кода. MAM же автоматически выкачает нужный репозиторий. А как в этих автоимпортах приятно разрешать конфликты — неописуемо просто.
длинные имена которые нужно писать каждый раз
Вам ничто не мешает сделать локальный алиас в любом месте, где вам будет удобно:
const table = $mol_log2_tableтакое бывает очень редко
В мозгу человека это бывает очень часто. Встретив класс Table вы не поймёте о чём идёт речь, пока не посмотрите откуда он импортируется. Особенно весело переключаться между файлами, где под одними именами прячутся разные сущности, а одни сущности под разными именами.
Автоимпорт не отработает для ещё не скачанного кода. MAM же автоматически выкачает нужный репозиторий.
Зачем? Я не добавляю по пакету в минуту, а раз в неделю написать в консоли npm i --save ngxs — у меня не составляет труда.
А как в этих автоимпортах приятно разрешать конфликты — неописуемо просто.
Можно пример?
Вам ничто не мешает сделать локальный алиас в любом месте, где вам будет удобно:
Чем тогда это лучше импорта? Если не брать автоматическое скачивание пакета
В мозгу человека это бывает очень часто. Встретив класс Table вы не поймёте о чём идёт речь, пока не посмотрите откуда он импортируется. Особенно весело переключаться между файлами, где под одними именами прячутся разные сущности, а одни сущности под разными именами.
В мозгу есть такая штука, как контекст, если вы работаете с чем-то достаточно давно — тогда мозг сам понимает, что это тут за table.
Если вы впервые в проекте — тогда вам все равно нужно будет разбираться что это за $mol_table
раз в неделю написать в консоли npm i --save ngxs — у меня не составляет труда.
А как часто вы проверяете какие модули пора бы удалить?
Чем тогда это лучше импорта?
Тем, что место любое, а не только начало файла. Вплоть до отсутствия локального алиаса — актуально, когда использование в файле единично.
В мозгу есть такая штука, как контекст
А у контекста есть такая характеристика, как размер. У человеков он не очень большой: https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B1%D0%BE%D1%87%D0%B0%D1%8F_%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D1%8C
Если вы впервые в проекте — тогда вам все равно нужно будет разбираться что это за $mol_table
Один раз разберётся и будет чёткая ассоциативная связь имени со смыслом. С короткими именами нужно постоянно держать в рабочей памяти ещё и постоянно меняющуюся таблицу мапинга имён на семантику.
Один раз разберётся и будет чёткая ассоциативная связь имени со смыслом. С короткими именами нужно постоянно держать в рабочей памяти ещё и постоянно меняющуюся таблицу ремапинга имён.
Вместо этого нужно держать путь к файлу, что ничем не лучше
ведь $mol_view — это mol/view, если этот путь будет сложнее — тогда это то же самое что запоминать алиас, а если путь изменится — тогда кроме рефакторинга придется запоминать новое название, не нужно выставлять свое решение как серебряную пулю, у него не меньше минусов чем в критикуемом вами
А как часто вы проверяете какие модули пора бы удалить
Убираю модуль из кода — нажимаю command + b что-бы посмотреть используется где-то модуль в проекте или нет, если нет — удаляю из package.json,
не нужно выставлять свое решение как серебряную пулю
Не помню, чтобы я таким занимался. Я объяснил, почему было выбрано именно это решение.
Убираю модуль из кода — нажимаю command + b
И никогда не забываете?
Не помню, чтобы я таким занимался. Я объяснил, почему было выбрано именно это решение.
Так почему именно ваше решение? Если оно в конечном итоге не лучше чем общепринятое?
И никогда не забываете?
Нет, а как можно забыть? Может у меня не такие огромные проекты, что-бы было миллион установленных сторонних пакетов.
Например в проекте на angular у меня обычно:
@ngxs, @ngxs-labs/data, angular/cdk, until-destroy, lodash-es, очень редко устанавливаем что-то еще
На тему автоимпорта есть такое исследование:
https://gist.github.com/zerkalica/d69c267d4bbac9cd49047e22336d5110
Впору в компанию к инженеру по настройке WebPack уже начинать нанимать инженера по настройке автоимпортов.
Чувство прекрасного снова подвело, учитывая картинку к посту. По фреймворку: Дмитрий просто занимается творчеством.
Конечно, можно из буханки хлеба сделать троллейбус — но зачем?
В целом по CSS-in-code решениям — я за весь свой програмистский опыт так и не увидел другого способа держать CSS в чистоте без выделения на это отдельного специального человека. То есть да, в идеале бы пользоваться нативными таблицами стилей и ничего не выдумывать, но на практике на любых не write once проектах это превращает CSS в гадюшник из неиспользуемых и плохо организованных стилей, в который надо отдельно ходить делать там уборку. Регулярно — поэтому и в некотором пределе проблема превращается в «нам нужен отдельный человек на должность клининг-менеджера CSS».
С занесением CSS в код — его становится возможным обрабатывать, как код. То есть, например, проверять ссылки на используемость линтером — отлетает проблема неиспользуемых стилей; или проверять синтаксическую валидность — отлетает проблема «опечатался в одной букве и что-то где-то может непоправимо полететь», например, кнопка важная пропадёт. Плюс, организация CSS начинает естественным образом цепляться к организации кода, а не быть совершенно отдельной сущностью. Плюсов много, и они очень весомые. Плата за них — отсутствие стандартизации этого всего зоопарка (впрочем, навести мосты к системам, могущим принимать/выдавать обычный css, как тот же emotion — несложно), плюс пострадавшее быстродействие. Например, styled-components в прошлом (не знаю, как сейчас) сами по себе давали ну очень даже неиллюзорные тормоза.
отлетает проблема «опечатался в одной букве и что-то где-то может непоправимо полететь», например, кнопка важная пропадёт
Извольте! Отсутствие опечаток не гарантирует того, что все отобразится как на макете дизайнера. И Вам в любом случае это надо проверять (пример — тесты скриншотами). А если это нужно проверять, то каки-либо преимуществ от того, что в стилях у вас TS (и это уже вовсе не стили, а js-код) — нету, по сравнению, скажем, со здоровым CSS-In-JS:
const Button = styled.a`
background: transparent;
color: white;
border: 2px solid white;
`Линтер не пропустит опечатки в прод, удобство работы с css сохранено (форматирование, копи-паста из браузера и прочие ништяки), тесты писать так и так нужно.
опечаток не гарантирует того, что все отобразится как на макете дизайнера
Зато гарантирует что не отобразится.
А если это нужно проверять, то каки-либо преимуществ от того, что в стилях у вас TS (и это уже вовсе не стили, а js-код) — нету
Слишком категорично. Автоматическая проверка всегда большое подспорье. Вопрос лишь приносит ли она больше пользы, чем вреда. Что в случае этого топика не очевидно (слишком много возни и итоговый json-подобный вид имхо это боль).
Следуя вашему аргументу легко придти к:
- тесты не нужны, всё равно руками проверять
- типы не нужны, всё равно руками проверять
- линтеры не нужны, ...
тесты не нужны, всё равно руками проверять
Я наоборот за тесты, поэтому и приводил как пример тестирование скриншотами. Даже в условиях строгой типизации тестами проверяют корректность бизнес логики (я про код в данном случае, а не про стили).
Следуя вашему аргументу легко придти к:
типы не нужны, всё равно руками проверять
линтеры не нужны, ...
Вы слишком смело расширили контекст css на область разработки целиком. Мои высказывания касались лишь css в виде JS объектов с TS против css в виде css с линтерами. Где я как раз аргументировал за линтеры и тесты.
Статья не о моле, а о его системе статической стилизации. Если интересно почитать конкретно про мол, и как он решает все остальные проблемы человечества, то я дал ссылки на соответствующие статьи выше: https://habr.com/ru/post/523646/#comment_22189110
Статья не о моле
Мне кажется вы разучились писать статьи не о $mol. Я думаю даже если вы напишете статью "Как построить скворечник" там будет опросник про $mol и пару абзацев про кривые фронтенд фреймворки :)
Вроде толковая статья, как минимум, с точки зрения — как заставить TS плясать по своим правилам. Я почерпнул для себя пару интересных моментов и даже поставил "+". Но думаю ваши пассажи про mol всё равно заруинят и рейтинг статьи, и вообще какое бы то ни было позитивное отношение к контенту.
Я полагаю у хабра-сообщества уже давно выработался рефлекс: "так что это у нас, о, интересно, ах блин опять этот $mol". И дальше критическое мышление слегка подотключается.
SASS + css modules идеально справляются с любым кейсом.
Даже если в процессе появятся какие-то неиспользуемые стили, вообще пофиг, ни на что не влияет.
Как обычно развели проблему на ровном месте, что проблемой не является вовсе. А вот говнокод который пишут тоннами, вот это настоящая проблема.
SASS + css modules идеально справляются с любым кейсом
Мой опыт показывает что всегда когда хочется сделать что-то "против шерсти" с css-modules возникают проблемы.
К примеру для css-modules есть линтер, который даже умеет проверять есть ли в файле не используемые стили. Но, он работает только для "1 TS\JS файл = 1 CSS файл" подхода. Что лично мне кажется часто неудобным. И тут либо пишешь как все и не выпендриваешься. Либо уже далеко не любой кейс решается.
Или скажем нужно импортировать какое-то имя класса из другого модуля. А нельзя. Точка. Они полностью независимы. Да в этом есть резон. Но когда нужно скосить углы, в виду какой-нибудь специфики… нельзя скосить углы.
Или скажем хочется сделать набор переиспользуемых анимаций? А как? Похоже только через `:global()`` либо дубляж.
В css-modules многое можно было бы сделать… более гибким. Но ввиду их философии — никто не будет. Это можно по разному трактовать. И как "а нефиг писать говнокод" и как "смерительная рубажка от людей которые думаю что они умнее всех". Но одно точно — "идеально справляются с любым кейсом" это ложь.
Добавить к этому что и у SCSS\SASS есть свои проблемы. И получаем что нет никаких идеальных инструментов. Есть только набор компромиссов.
Похоже только через `:global()`` либо дубляж.
Анимация либо глобальная, либо дубляж. Логично
Или скажем нужно импортировать какое-то имя класса из другого модуля. А нельзя. Точка. Они полностью независимы.
Можно подробнее кейс? import styles from "shared.module.css" валидная конструкция, так можно делать хоть в нескольких файлах. А что тогда подразумевается под "А нельзя. Точка."?
Можно подробнее кейс? import styles from "shared.module.css" валидная конструкция,
Нужно только имена классов получить, для каскада. Не стили.
Анимация либо глобальная, либо дубляж. Логично
Для сравнения в мире JS такой проблемы не стоит. Есть импорты и экспорты. Не приходится ничего хардкодить.
import styles from "shared.module.css" валидная конструкция, так можно делать хоть в нескольких файлах
Хм. Я не обратил внимание на синтаксис. Вы тут про JS. А я про нечто подобное:
@import styles from './somepath.mod.scss';
.myClass ${style.otherModuleClass} {
}Вот про такое. Без CSS modules (голый глобальный CSS без ограничений) такое делается без каких-либо проблем. Многие другие решения из области CSS-in-JS на уровне уже webpack-импортов такое делают без проблем. В CSS-modules ЕМНИП так нельзя по причине идеологии чистого css кода.
Но я мог что-то напутать или времена могли измениться.
Фантастика конечно. Как писать код так, чтобы его точно никто не понял. Мелькнули и сгорели фантазийные Sass (в синтаксисе на отступах) и CoffeeScript — их заменили Sass (SCSS) или CSS и JS/TS в совместимом и понятном виде. Но нет — найдутся желающие так же сверкнуть и невостребовано сгореть.
csstype@3: кривая типизация с подсказками
По спецификации свойство display может состоять из двух слов. Например
display: inline flex;Описывать такое в TS было бы достаточно многословным (перечислять все комбинации). Кстати, возможно, в будущем с этим сможет помочь template literal types из TS 4.1.
Я так понимаю, что | string в csstypes для свойства display добавлен как раз для того, чтобы полный двухсловный синтаксис не ломал тайпскрипт.
Как с этим обстоит у $mol?
Конкретно для display двойная форма ещё не поддерживается браузерами, так что типизирована лишь одинарная. Но по другим свойствам — используется подход со списками:
type ContainRule = 'size' | 'layout' | 'style' | 'paint'
/** Indicate that an element and its contents are, as much as possible, independent of the rest of the document tree. This allows the browser to recalculate layout, style, paint, size, or any combination of them for a limited area of the DOM and not the entire page, leading to obvious performance benefits. */
contain?:
| 'none' | 'strict' | 'content'
| ContainRule | ContainRule[]
| CommonС практической точки зрения двойная форма display пока не нужна, согласен. Но формально вы затипизировали подмножество css. Как вспомогательный инструмент для конкретного фреймворка — вполне пойдет.
Contain у вас выглядит лучше, чем в csstypes. Интересно, почему в csstypes не сделали так же через массив. Возможно, из-за особенностей выгрузки формата из MDN (там же типы не вручную прописываются, а генерятся прямо из спецификации).
На самом деле, насколько я вижу, основное отличие даже не в этих отдельных случаях, а в в shorthand-свойствах типа background. У вас по сути свой dsl для их описания (в виде вложенного объекта), из-за чего это еще плюс один синтаксис, который надо знать. Зато типизировать его гораздо проще, чем оригинальный формат.
Продвинутый CSS-in-TS