А кому нужны изменения в реальном мире? Может человеку на них плевать, но ему нравится играть в игры? А кому-то нравится жить в тайге одному, люди сами выбирают как им жить, главное выбрать то, о чем не будешь жалеть перед смертью
Спасибо за статью, недавно решал подобную задачу для древовидных комментариев, до этого момента не знал, что у компонентов может быть рекурсия, все оказалось очень просто)
По вашим ответам мне кажется, что вы никогда не верстали ничего сложнее карточки с заголовком, картинкой и кнопкой, у вас нет дизайнера? я не буду дальше спорить, не все живут в идеальном мире, удачи.
А потом h2 заменили на h3 и стили слетели
А если отступ нужен для одного элемента другой — уже нужен класс. Для последнего сделали через :last-child, а потом добавился ещё один блок и нужно переделывать
Впору в компанию к инженеру по настройке WebPack уже начинать нанимать инженера по настройке автоимпортов.
А есть такие? Я бы нанял
А если серьезно, то обычно в шторме все работает из коробки, а настройку вебпака в моем случае на себя берет angular-cli, так же unused imports удаляются при коммите
Не помню, чтобы я таким занимался. Я объяснил, почему было выбрано именно это решение.
Так почему именно ваше решение? Если оно в конечном итоге не лучше чем общепринятое?
И никогда не забываете?
Нет, а как можно забыть? Может у меня не такие огромные проекты, что-бы было миллион установленных сторонних пакетов.
Например в проекте на angular у меня обычно:
@ngxs, @ngxs-labs/data, angular/cdk, until-destroy, lodash-es, очень редко устанавливаем что-то еще
Один раз разберётся и будет чёткая ассоциативная связь имени со смыслом. С короткими именами нужно постоянно держать в рабочей памяти ещё и постоянно меняющуюся таблицу ремапинга имён.
Вместо этого нужно держать путь к файлу, что ничем не лучше
ведь $mol_view — это mol/view, если этот путь будет сложнее — тогда это то же самое что запоминать алиас, а если путь изменится — тогда кроме рефакторинга придется запоминать новое название, не нужно выставлять свое решение как серебряную пулю, у него не меньше минусов чем в критикуемом вами
А как часто вы проверяете какие модули пора бы удалить
Убираю модуль из кода — нажимаю command + b что-бы посмотреть используется где-то модуль в проекте или нет, если нет — удаляю из package.json,
Автоимпорт не отработает для ещё не скачанного кода. MAM же автоматически выкачает нужный репозиторий.
Зачем? Я не добавляю по пакету в минуту, а раз в неделю написать в консоли npm i --save ngxs — у меня не составляет труда.
А как в этих автоимпортах приятно разрешать конфликты — неописуемо просто.
Можно пример?
Вам ничто не мешает сделать локальный алиас в любом месте, где вам будет удобно:
Чем тогда это лучше импорта? Если не брать автоматическое скачивание пакета
В мозгу человека это бывает очень часто. Встретив класс Table вы не поймёте о чём идёт речь, пока не посмотрите откуда он импортируется. Особенно весело переключаться между файлами, где под одними именами прячутся разные сущности, а одни сущности под разными именами.
В мозгу есть такая штука, как контекст, если вы работаете с чем-то достаточно давно — тогда мозг сам понимает, что это тут за table.
Если вы впервые в проекте — тогда вам все равно нужно будет разбираться что это за $mol_table
Любители верблюдов обычно убеждены сами и пытаются убедить всех окружающих, что второе читать легче. Однако, это не так. Первая форма записи лишена неоднозначностей с аббревиатурами и слова чётко различимы, а не сливаются в единое полотно. Обоснование можете почитать тут: github.com/eigenmethod/mol/wiki/PascalCase-camelCase-kebab-case-snake_case
По поводу пункта «Проблемы с аббревиатурами: mxBADownload» соглашусь, по поводу остального — нет, когда много кода — camelCase элементарно компактнее и опрятнее смотрится, из-за чего легче воспринимается, а с монохромным шрифтом отлично читается
все эти плюсы переплюнет автоимпорт от любой нормальной ide
в итоге минусы остаются, а именно: длинные имена которые нужно писать каждый раз, вместо импорта вверху файла который делается автоматом и скрыт от глаз по умолчанию
Если есть конфликт имен — в импорте можно сделать {user as molUser}, но такое бывает очень редко
а чем у вас хороший? Зачем мне эти $/\_? $.$$ когда можно обойтись без них?
это удобно писать? Вместо того, что-бы писать переменную только буквами, вы к ней еще предлагаете $_ или $mol_
что читабельней
$mol_table
или
table?
а если название будет длиннее?
$mol_users_table_for_students_page
или
UsersTableForStudentsPage
А кому нужны изменения в реальном мире? Может человеку на них плевать, но ему нравится играть в игры? А кому-то нравится жить в тайге одному, люди сами выбирают как им жить, главное выбрать то, о чем не будешь жалеть перед смертью
Потому-то пишут в одном файле и невозможно поддерживать)
А потом h2 заменили на h3 и стили слетели
А если отступ нужен для одного элемента другой — уже нужен класс. Для последнего сделали через :last-child, а потом добавился ещё один блок и нужно переделывать
А есть такие? Я бы нанял
А если серьезно, то обычно в шторме все работает из коробки, а настройку вебпака в моем случае на себя берет angular-cli, так же unused imports удаляются при коммите
Так почему именно ваше решение? Если оно в конечном итоге не лучше чем общепринятое?
Нет, а как можно забыть? Может у меня не такие огромные проекты, что-бы было миллион установленных сторонних пакетов.
Например в проекте на angular у меня обычно:
@ngxs, @ngxs-labs/data, angular/cdk, until-destroy, lodash-es, очень редко устанавливаем что-то еще
Вместо этого нужно держать путь к файлу, что ничем не лучше
ведь $mol_view — это mol/view, если этот путь будет сложнее — тогда это то же самое что запоминать алиас, а если путь изменится — тогда кроме рефакторинга придется запоминать новое название, не нужно выставлять свое решение как серебряную пулю, у него не меньше минусов чем в критикуемом вами
Убираю модуль из кода — нажимаю command + b что-бы посмотреть используется где-то модуль в проекте или нет, если нет — удаляю из package.json,
Зачем? Я не добавляю по пакету в минуту, а раз в неделю написать в консоли npm i --save ngxs — у меня не составляет труда.
Можно пример?
Чем тогда это лучше импорта? Если не брать автоматическое скачивание пакета
В мозгу есть такая штука, как контекст, если вы работаете с чем-то достаточно давно — тогда мозг сам понимает, что это тут за table.
Если вы впервые в проекте — тогда вам все равно нужно будет разбираться что это за $mol_table
По поводу пункта «Проблемы с аббревиатурами: mxBADownload» соглашусь, по поводу остального — нет, когда много кода — camelCase элементарно компактнее и опрятнее смотрится, из-за чего легче воспринимается, а с монохромным шрифтом отлично читается
Тот, который импортнули в начале файла
все эти плюсы переплюнет автоимпорт от любой нормальной ide
в итоге минусы остаются, а именно: длинные имена которые нужно писать каждый раз, вместо импорта вверху файла который делается автоматом и скрыт от глаз по умолчанию
Если есть конфликт имен — в импорте можно сделать {user as molUser}, но такое бывает очень редко
это удобно писать? Вместо того, что-бы писать переменную только буквами, вы к ней еще предлагаете $_ или $mol_
что читабельней
$mol_table
или
table?
а если название будет длиннее?
$mol_users_table_for_students_page
или
UsersTableForStudentsPage
Это фишка автора, как раз из-за таких вот фишек фреймворком мало кто пользуется.
Вам решать, но хороший код стайл не менее важен чем хорошая архитектура
Это как так? Разве это не нарушает правила ресурса?