Привет. Недавно пришлось повозиться с @tanstack/vue-table. Задача была стандартная: нужна таблица с сортировкой, фильтрами и редактированием ячеек. Казалось бы - идеальное время подключить готовое решение. Но не всё так гладко. Делюсь мыслями, граблями и тем, как я в итоге выкрутился.

Собеседования по TypeScript всё чаще проверяют не только знание синтаксиса, но и умение видеть «узкие места» в уже работающем коде. Задача кандидата - не просто сказать «тут ошибка», а предложить более безопасное, читаемое и поддерживаемое решение.

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

Правильная файловая структура - скелет любого фронтенд-приложения. В Vue 3 нет строгих предписаний, как раскладывать файлы по папкам, кроме базового разделения components/, views/. Но с ростом проекта хаотичное размещение кода быстро превращается в проблему. В этой статье разберём популярные подходы к организации Vue-проектов: от простейшего плоского до микрофронтендов.

Сегодня мы с вами поговорим о вещи, на первый взгляд, простой до банальности: почему важно хвалить сотрудников и проявлять к ним внимание. Тема, кажется, даже не заслуживает отдельного разговора - ну кто же не знает, что доброе слово приятно? Но вот парадокс: по моим личным наблюдениям (статистику я, конечно, не публикую, все взято из моей головы), компании редко хвалят коллег за сделанную работу. Я не о том, чтобы каждые две-три недели гладить человека по головке за сам факт его существования - разумеется, нет. Речь о другом - о простом, почти забытом искусстве замечать усилия.

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

Сегодня посмотрим на вымышленный пример, как не надо делать стор. Любые совпадения - случайность. Все истории выдуманы.

Представьте: есть у нас герой Алекс. Перекидывают его на проект - «поправить пару простых багов, делов на пять минут». Открывает Алекс код, а там… У него сердце замирает. Подумаешь, с кем не бывает. Но внутри начинается дилема: просто пофиксить баги и забыть этот ужас как страшный сон, либо как настоящий богатырь проектов взять и отрефакторить весь этот бардак. Сделать по-человечески, заложить нормальную основу. Да, потом спросят за новые баги - ну и что. Зато внутри тепло разольётся, что не забил на плохой код и навёл порядок.

Сегодня разберём тему, которая кажется элементарной, но на практике вызывает кучу вопросов. Речь о кнопке «Назад» в приложении на Vue.

Казалось бы, что тут сложного? Кликнули - ушли на предыдущую страницу. Но нет. Большинство разработчиков, даже с опытом, не до конца понимают, как устроена навигация в роутерах и как работает история браузера. А это критично, когда речь заходит о предсказуемом поведении приложения.

Методологию БЭМ придумали в Яндексе больше десяти лет назад. За это время фронтенд сильно изменился: появились компоненты, фреймворки, утилитарные классы и прочее. Казалось бы, БЭМ должен был уйти в архив. Но нет - он до сих пор спасает проекты от CSS-хаоса. Особенно когда речь заходит о Vue.

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

Сегодня я не буду читать лекций. Просто поделюсь тем, как сам дошел до более-менее устойчивого подхода после того, как неоднократно рефакторил чужие сторы и ловил себя на мысли: «Зачем я это трогал?». Возможно, где-то я буду неправ, возможно, в вашем проекте это не взлетит. Я не напрашиваюсь в учителя, просто фиксирую опыт, чтобы не наступать на одни и те же грабли.

Как правильно называть маршруты в Vue Router: два простых правила, которые спасут ваш проект:

1. Первое правило: всегда задавайте name

2. Второе правило: храните имена в enum (или константном объекте)

На дворе 2026-й, и за это время как React, так и Vue сделали гигантский скачок в развитии и создании экосистемы вокруг себя. Но статистика до сих пор беспощадна к Vue. На React в два раза больше вакансий, чем на Vue. Сколько я ни спрашивал React-инженеров, ответ был всегда один и тот же: «React для серьезных проектов, а Vue так уж».. Серьезно? Почему вы до сих пор так думаете?? Ну хоть один пример приведите, что нельзя сделать во Vue. Хотя бы потратьте 1 день на изучение экосистемы Vue 3 Composition API, Vue Router, Pinia - да вы после этого забудете про свой React. А про различные useState я вообще молчу, Vue тут вообще вас всех обошел с обычными ref. Это вы еще не слышали про keep-alive.

Я считаю, что такое мнение построилось из-за простой причины: люди просто поставили свою карьеру на React, вот почему они его защищают, а компании продолжают его использовать.