решил свой вопрос. grid-template-rows: max-content max-content auto;

Лисица рыдает и говорит  НЕ ВЕРЮ

grid-template-rows: auto auto 1fr;

спасибо, что ты есть. действительно лиса не верит.

У меня проект есть который писал давно. я хотел бы каким-либо инструментом отформатировать весь код там. может Prettier для этого подойдёт? есть какая-то команда чтобы Prettier все файлы в папке отформатировал?

если ИДЕ вебшторм - правый клик по папке-реформат-указать пространство для форматирования. Переформатирует все что укажешь

+ наверное есть какие-то стайлеры которые следят за общими правилами, которые приняты в команде

Всем привет!) Кто-то на фронте юзает unit тесты?

😅

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

У нас тут просто поднялась тема про тесты на фронте, я начала копать и наткнулась на unit тесты и интеграционные тесты, взялась смотреть unit и пока не вижу прям такой лютой необходимости в них...хотелось бы узнать у людей, которые их таки пишут, какой профит и мнение, надо ли)

Казалось бы, в краткосрочной перспективе - не надо. Вы все помните, каждая функция работает как часы, о рефакторинг даже разговоров нет, а таски не изменяют текущий функционал а рядом, дополняют новым, не пересекающимся

В долгосрочной перспективе, код становится похож на минное поле, в которое, порой, вкидывпется новый разраб и любой шаг в лево или право ломает фронт. И ладно бы, если очевидно, но ведь узкий кейс, пограничной состояние, цена которого - потеря прибыли компании в миллионы рублей

А попробуйте сделать рефакторинг кода, без юнит тестов и вы поймёте, что не можете контролировать все возможные состояния программы, куда попадает этот код

Я уж не говорю, что порой юнит тесты, более описательны чем типы ts или jsdoc

Да и писать фронт, не теребонькая регулярно бандл на пересборку - приятная опция

вообще по уму - это отдельная специализация, потому как разработчику всегда хочется писать код а не тесты, ибо любят (в хорошем смысле при выполненной и в плохом при не выполненной работе) его не за прекрасные тесты . Если же ты человек-оркестр, то выбора нет)) только с юнит-тестами большой вопрос что именно тестировать. При грамотной архитектуре - тестить по сути надо только то, что компонент отдает наружу. То есть тест = публичный контракт. Если он исполняется - все ок. Тут тоже вилка)) если так делать, то покрытие будет ну так себе. И велик соблазн "побырому"покрыть все "тестами" которые ничего не проверяют. Ну а дальше в дело вступает дисциплина, самоконтроль и регламенты) Если требуют 100: покрытие и не смотрят какое оно - очень скоро весь код будет покрыт "тестиками ни о чем", или над разработчиком засияет нимб праведника)

Отдельная специализация что бы писать юнит тесты на твой код?) окей) На скок мне известно, разраб любят не за то что он пишет код, а за решение вопроса автоматизации бизнеса.

тоже позиция)

Мнение от бэка - нужны ибо они быстрей чем прочии тесты

Не согласен ибо тдд не про qa и тесты не для дяди с деньгами нужны, а для себя любимого

Горячий пример. На этой неделе обновлял зависимости в проекте. Без тестов я бы перегрузил qa тоннами багов и задача летала бы от меня к ним туда обратно еще пару недель. Но поскольку в команде принято писать юнит тесты. Первый же прогон показал что есть проблемы. На решение которых потребовалось несколько часов.

Возвращаясь же к тдд - очень сложно сломать себя в сторону написания кода через тесты. Но когда начнешь практиковать. То, во первых, код начнет получаться чище. Во вторых, проекты без тестов начнут казаться теми кошмарами, где вы в школу/офис приходите без штанов и трусов.