Я немного про другое. - Можно было бы добавить тип для класса(PromiseImplementation<T>) и пробросить его в resolve, чтобы было не (argument?: any) => void , а (argument?: T) => void и тогда этот тип можно использовать для then (argument?: T) => any;
- Когда у нас есть цепочка промисов, можно добавить получение типа для then на основе возвращаемого значения.
В худшем случае да, но как будто можно вместо Nested Routes просто задавать строкой нужный путь
Иногда бывает необходимо сделать именно несколько уровней вложенных маршрутов.
К сожалению, да, ведь эти файлы вставляются в prependData и поэтому являются глобальными. И поэтому же там не может быть CSS селекторов и тд, то есть только SCSS и ничего больше.
Я на проекте делал похожее разделение на модули, думал над таким вариантом добавления scss, но отказался из-за того что могут быть пересечения переменных между сервисами. Решил что лучше просто импортировать файл с глобальными scss переменными сервиса в нужный компонент.
А если вам надо добавить вложенный маршрут(в рамках сервиса нужно выделить несколько модулей)? Находите нужный элемент в routes и делаете push в children?
scssVariables: [
{
//join всё также нельзя
src: __dirname + '/scss/microModuleVariables.scss',
strategy: 'push',
},
],
scssVariables доступны глобально по всему приложению или только в рамках модуля в котором они подключаются?
Очень часто встречающаяся ошибка: обвинение всех вокруг в возникновении технического долга. Наверняка вы видели, как некоторые сотрудники (инженеры, продакт-менеджеры) говорили коллегам что-то вроде «Если бы вы сразу придумали лучшее решение, то эта ситуация не возникла бы». Это глупые, нечестные и бессмысленные обвинения.
Идеал недостижим. Мы — люди, контекст постоянно меняется, технологии развиваются. Это надо просто принять. Лучшее, что могут сделать разработчики и иже с ними — это учиться на своих ошибках, внедрять передовой опыт и максимально полно осознавать компромиссы, на которые идут при разработке продукта.
Я с вами полностью согласен, только вот как быть если сотрудник не хочет делать выводы из своих ошибок?
Да, с типизацией скрипта во Vue 3 проблем быть не должно, но я говорю именно про шаблон(<template></template>), информации о том, что данную проблему решили я не нашел.
Если я правильно понял, получится что-то очень сильно напоминающее инкрементальный ребилд, который есть во всех основных инструментах сборки.
Нет, я не про это.
Я говорю про сборку пакетов и публикацию их во внешние источники(к примеру azure artifacts, ну или npm). 1) Вы собирате пакет 2) Публикуете его 3) Устанавливаете его к себе в проект(как обычный пакет из npm) и используете.
В момент старта проекта выбрали webpack. Если бы начинали проект сейчас — это гарантированно был бы esbuild, swc или другие экспериментальные проекты. Возможность срезать лишнюю минуту из билда, если помножить её на годы работы — бесценна.
а вы не рассматривали варианты предварительной сборки компонентов(правда, тогда придется где то хранить собранные версии) с целью ускорения процесса сборки всего проекта?
Я согласен, что многое зависит от возможностей команды, просто у нас при переходе на typescript получилось слишком много кода с any. В результате очень сложно поддерживать код, который был написан другим разработчиком, даже исправление казалось бы простых багов в таком коде бывает занимает значительно больше времени, чем ожидалось.
TypeScript выдает скомпилированный JavaScript код даже когда он видит ошибки. Вы должны отключить это вручную, используя флаг noEmitOnError. Тогда у вас останется старый код, даже когда компилятор кричит на вас. ывыв
Используйте any везде, где интеграция типов очень сложна или потребует много времени. Вопреки общественному мнению, использовать anyабсолютно нормально, до тех пор пока вы делаете это явно.
Если вы работаете в команде, то не стоит так делать. При переводе проекта на typescript лучше сразу указывать корректные типы(даже если для этого требуется много времени). Сталкивался с тем, что временно указав в коде any, разработчик, потом его просто забывает исправить.
Добрый день!
Я немного про другое.
- Можно было бы добавить тип для класса(PromiseImplementation<T>) и пробросить его в resolve, чтобы было не
(argument?: any) => void, а(argument?: T) => voidи тогда этот тип можно использовать для then(argument?: T) => any;- Когда у нас есть цепочка промисов, можно добавить получение типа для then на основе возвращаемого значения.
1) Думаю вам стоит добавить типы(generic) для метода then, не очень удобно, что сейчас у ConsumerCallback параметр argument всегда имеет тип any.
2) А почему вы не взяли queueMicrotask вместо setTimeout?
Иногда бывает необходимо сделать именно несколько уровней вложенных маршрутов.
Я на проекте делал похожее разделение на модули, думал над таким вариантом добавления scss, но отказался из-за того что могут быть пересечения переменных между сервисами. Решил что лучше просто импортировать файл с глобальными scss переменными сервиса в нужный компонент.
А если вам надо добавить вложенный маршрут(в рамках сервиса нужно выделить несколько модулей)? Находите нужный элемент в routes и делаете push в children?
scssVariables доступны глобально по всему приложению или только в рамках модуля в котором они подключаются?
Я с вами полностью согласен, только вот как быть если сотрудник не хочет делать выводы из своих ошибок?
Да, с типизацией скрипта во Vue 3 проблем быть не должно, но я говорю именно про шаблон(<template></template>), информации о том, что данную проблему решили я не нашел.
Разве во Vue 3 есть решена проблема проверки типов в шаблоне?
кажется нет, будет достаточно сложно добавить проверку типов для аргументов и модификаторов директив.
тут дело не в computed, а том что vue сам умеет формировать строку с названиями классов из объектов и массивов(примерно так же как и в clsx).
Нет, я не про это.
Я говорю про сборку пакетов и публикацию их во внешние источники(к примеру azure artifacts, ну или npm).
1) Вы собирате пакет
2) Публикуете его
3) Устанавливаете его к себе в проект(как обычный пакет из npm) и используете.
а вы не рассматривали варианты предварительной сборки компонентов(правда, тогда придется где то хранить собранные версии) с целью ускорения процесса сборки всего проекта?
Надеюсь так и будет, TypeScript существенно упрощает поддержку кода, но к сожалению, далеко не все фронтендеры признают его пользу.
Все же has - это псевдокласс, а не псевдоэлемент.
Почему в вашей карте компетенций "шаблонизаторы и их принципы(Pug, Twig)" находятся разделе Middle?
Я согласен, что многое зависит от возможностей команды, просто у нас при переходе на typescript получилось слишком много кода с any. В результате очень сложно поддерживать код, который был написан другим разработчиком, даже исправление казалось бы простых багов в таком коде бывает занимает значительно больше времени, чем ожидалось.
Если вы работаете в команде, то не стоит так делать. При переводе проекта на typescript лучше сразу указывать корректные типы(даже если для этого требуется много времени). Сталкивался с тем, что временно указав в коде any, разработчик, потом его просто забывает исправить.