Svelte-разработчик: портфолио без учебных клонов

Выберите продуктовый кусок вместо очередного клона

Клон магазина или todo-приложение показывает, что разработчик прошёл документацию, но почти не создаёт предмета для разговора. Для портфолио Svelte лучше взять ограниченную реальную задачу: каталог с фильтрами и URL-state, редактор с autosave, аналитический экран с большим набором данных, offline-first заметки или booking flow. Важны конкурирующие требования, потому что именно на них видно инженерное решение.

Сформулируйте сценарий и ограничения до кода. Кто пользователь, какое действие критично, что должно работать без JavaScript, какие данные меняются, нужен ли SSR, как выглядит медленная сеть? Определите два-три качества, которыми проект будет отличаться: мгновенный feedback при фильтрации, восстановление черновика после сбоя, доступная клавиатурная навигация или стабильный layout. Большой список функций размывает proof; одна законченная вертикаль даёт архитектуру, UI и эксплуатацию.

Не прячьте происхождение идеи. Если задача основана на реальном процессе знакомого бизнеса, обезличьте данные и опишите интервью. Если это собственная гипотеза, назовите допущения. Покажите выбор: почему Svelte подходит — компактная реактивная модель, SSR через SvelteKit, удобная компиляция компонентов — и что было бы проще на другом стеке. Заявление «выбрал из-за скорости» без профиля нагрузки звучит рекламой технологии.

Сделайте репозиторий воспроизводимым. README должен содержать цель, архитектурную карту, команды, переменные окружения без секретов, тестовую учётную запись или seed и известные ограничения. Живой demo полезен, но не заменяет читаемый код. Добавьте журнал двух архитектурных решений в формате context, options, choice, consequence. Например, почему фильтры стали URL-state, а не global store, и почему публичная страница использует server load. Короткий ADR показывает способность выбирать и пересматривать, тогда как диаграмма только фиксирует текущую форму. Укажите условие, при котором решение перестанет подходить. Приложите data-flow trace одного действия. Пользователь меняет фильтр, маршрут обновляет URL, load получает параметры, server возвращает страницу, UI восстанавливает focus. На таком маршруте видны двойной fetch, лишняя запись store и потеря history. Отметьте, какой слой валидирует параметр и как неизвестное значение превращается в безопасное состояние. Сравнить требуемые навыки можно по вакансиям frontend-разработчиков, отбирая позиции, где Svelte указан в стеке или допускается как специализация.

Докажите понимание реактивности и состояния

Реактивность Svelte уменьшает boilerplate, но не отменяет проектирование данных. Разделите локальное UI-состояние, состояние URL, server data и долговечный черновик. Фильтр, которым можно поделиться, должен жить в query parameters; раскрытый accordion обычно остаётся локальным; данные пользователя приходят через load и invalidation; незавершённая форма требует устойчивого хранения и conflict policy. Если всё помещено в один global store, зависимости становятся невидимыми.

Покажите derived state, а не синхронизацию копий. Если итоговая сумма вычисляется из позиций, храните позиции и формулу; второй writable total быстро расходится. Side effect отделяйте от вычисления: аналитика, autosave и обращение к browser API требуют lifecycle и защиты от SSR. Укажите, как прекращается подписка или запрос при уничтожении компонента и как обрабатывается гонка между двумя сохранениями.

Для списка добавьте стабильный key и объясните идентичность элемента. Индекс массива ломает локальное состояние при reorder. Для асинхронного поиска отменяйте устаревший запрос либо сравнивайте request token, иначе медленный ответ перезапишет свежий. Такие детали лучше отдельной сотни компонентов: они показывают понимание исполнения, а не только синтаксиса шаблона.

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

Спроектируйте SSR и границу браузера

SvelteKit позволяет отрендерить страницу на сервере, но проект должен осознанно разделять окружения. Доступ к window, localStorage и ResizeObserver размещайте в browser-only lifecycle или модуле, который не импортируется сервером. Не лечите ошибку проверкой в случайном месте: покажите, почему компонент может выполнить module scope при SSR. Для данных выберите server load, universal load или client fetch по требованиям к секретам, SEO и персонализации.

Публичный каталог выигрывает от server render: пользователь и crawler получают содержание, а hydration добавляет интерактивность. Персональная панель тоже может загружаться на сервере, если auth проверяется в hooks и данные не попадают в общий cache. Тяжёлый интерактивный редактор допустимо частично отложить, но skeleton должен сохранять размеры. Объясните выбор для каждой страницы, а не включайте SSR ради отметки в резюме.

Обработайте состояния маршрута: loading, empty, validation error, 404, 500 и retry. Form actions полезны для progressive enhancement: базовая отправка работает без client script, а enhance добавляет optimistic UI и локальный feedback. При optimistic update храните способ rollback и различайте validation conflict от сетевого отказа. Не показывайте успех до подтверждения, если операция создаёт необратимое действие.

Схема связывает маршрут, server data, локальную реактивность и проверки качества перед релизом.

Измерьте производительность, а не повторяйте тезис о лёгкости

Небольшой runtime не гарантирует быстрый продукт. Измерьте загрузку demo на мобильном профиле: JavaScript, изображения, шрифты, LCP, INP и layout shifts. Затем проведите один эксперимент. Например, вынесите тяжёлый редактор в dynamic import, замените библиотеку форматирования на серверную подготовку, добавьте responsive images или виртуализируйте таблицу. Приведите before/after с одинаковыми условиями и объясните trade-off.

Для длинного списка различайте цену DOM и цену данных. Pagination или windowing уменьшают узлы, но могут ухудшить поиск по странице и доступность. Иногда дешевле серверная пагинация с сохранением фильтров в URL. Если используете infinite scroll, оставьте reachable footer, фокус после подгрузки и явный конец. Производительность без доступности не считается улучшением.

Проверьте hydration. Разные значения времени, случайности или browser-only данных создают mismatch. Передавайте детерминированный snapshot или показывайте client value после mount без скачка layout. Отслеживайте duplicate requests: один и тот же endpoint не должен вызываться server load, client initialization и reactive effect. Network trace в кейсе доказывает это лучше утверждения об оптимизации.

Добавьте performance budget: предел initial JS, изображения, число запросов, допустимый p75 web vital. CI может проверять bundle diff или Lighthouse threshold, но число выбирается из сценария, а не из чужой статьи. Если hosting делает cold start, измерьте отдельно и не приписывайте его Svelte. Для зарплатного ориентира используйте страницу frontend-зарплат, учитывая, что код объединяет несколько специализаций.

Покажите поддерживаемость через изменения

Архитектуру легче оценить на второй функции. Добавьте требование после первой версии: новый тип фильтра, совместное редактирование, второй источник данных или иной layout. Расскажите, какие границы выдержали, а что пришлось переработать. Если компонент разросся до сотен строк, вынесите domain logic в тестируемый модуль, визуальные части — в небольшие компоненты, а сетевой контракт — в typed client. Не дробите код до папки из одноразовых обёрток.

Тестовая пирамида должна соответствовать рискам. Pure-функции фильтра и conflict resolution проверяются unit tests, компонент — interaction tests с клавиатурой и ошибкой API, критический маршрут — браузерным сценарием. Не тестируйте внутренние reactive переменные вместо поведения. Для accessibility добавьте semantic HTML, label, focus order, contrast и screen-reader announcements; автоматический axe полезен, но ручная клавиатура на ключевом flow обязательна.

Типизируйте границы, а не только props. Разберите API response схемой или generated types, обработайте неизвестное enum-значение и nullable поля. Ошибка на backend не должна превращаться в бесконечный spinner. Централизованный client может нормализовать transport errors, но UI различает, что пользователь способен исправить, а что требует retry. Покажите один failure path в demo: отключите сеть, сохраните черновик, восстановите соединение.

Завершите проект production-мелочами: CSP, безопасный render пользовательского текста, env validation, monitoring, source maps с контролем доступа, cache headers и preview deploy. Не надо строить корпоративную платформу вокруг портфолио. Достаточно выбрать риски своего сценария и закрыть их. В финальном разборе назовите технический долг и следующую точку пересмотра. Портфолио без учебного клона доказывает способность владеть изменением, а не способность повторить интерфейс.