План статьи
1) Вводная часть
2) Какие ошибки допустил при начале разработки фронта на админке и пути их решения
3) Выводы
Вводная часть
Всем привет, меня зовут Александр, я являюсь фронтенд разработчиком с 4-х летним опытом работы. Не смотря на то, что у меня много опыта в разработке проектов, но с нуля я начинал только один проект в коммерческой разработке и теперь я начинаю свой собственный проект, и конечно же без ошибок здесь тоже никуда).
И в этой статье я бы хотел с вами поделиться какие ошибки я допустил во время начала разработки своей админки под главную страницу своего блога.
Какие ошибки допустил при начале разработки фронта на админке и пути их решения
Начнем, наверное, с того, что я долго думал, что лучше: готовая тема админки или разработать свою с нуля на основе готовых решений. Я понимал, что использование готовых решений может наложить некоторые ограничения на разработку, но решил, все-таки, что у меня получится обойти ограничения. Поэтому сначала воспользовался готовой темой для админки coreUI. К сожалению, во время подключения бизнес логики к форме регистрации у меня не получилось подружить форму из этой темы и пакет react-hook-form. В следитствии этого, мною было принято решение отказаться от использования этой темы и сделать свою на основе готовых решений, а верстку сделать самому.
Идем далее, в процессе работы, я допустил недоработку своего первоначального шаблона, которые теперь необходимо было поправить. Далее будет описано какие проблемы были обнаружены и исправлены в моем шаблоне.
С первой проблемой с которой я столкнулся — это не сохранялся переход между страницами. То есть, можно было перейти на другую страницу (в адресной строке от корневой страницы переходишь на другую по сайту). После этого перезагружаешь страницу и у пользователя вылетает ошибка, что такой адрес нельзя обработать.
На скринах выше приведен пример, где для вышеописанной проблемы в объект output был добавлен publicPath, а в объект devSerer — historyApiFallback. Таким образом, проблема с переходами между страницами была решена.
Далее, создание алиасов и их чтение webpack и линтером. Здесь под ошибкой я подразумеваю, то что необходимо иметь возможность писать относительный путь до файлов, чтобы избежать длинный путь.
На вышеописанных скринах описано, что для того, чтобы относительные путя работали в проекте, то для этого необходимо прописать все относительные путя сначала в файле tsconfig, чтобы линтер понимал этот путь, а потом еще в файле webpack.config, чтобы при сборке конфиг понимал какие файлы брать по такому пути.
На скрине выше мною приведен пример использования готового алиаса в самом проекте для понимая зачем они нужны.
Также забыл добавить менеджер стейта для react, поэтому также добавлю потом его в свою сборку. Почему я сюда занес проблему? Потому что не знал, как лучше обрабатывать запросы на бекенд. Один из вариантов решения — это использовать ли вызов через dispatch? В итоге, после долгих раздумий я решил использовать простой вызов через fetch и возвращать результат в компонент, откуда был произведен вызов. Почему именно так? Потому что я считаю, что код должен быть простым и понятным и усложнять его присоединением dispatch я не хочу.
Также хотел добавить дилему, как хранить данные токенов, которые буду получать с бекенда для авторизации. В одно время я для себя изучал данную проблему и не смог найти сто процентного решения для данной проблемы. В local storage данные могут похитить, в заголовках перехватить. Одним из безопастных способов передачи были http куки, но в них на фронте нельзя передать данные. Поэтому на данный момент, я для себя принял решение, что буду передавать по заголовкам и у токенов будет короткое время жизни, чтобы можно было поддерживать безопастность. В будущем к этому вопросу еще вернусь.
Очередной проблемой стал выбор стилизации компонентов: через файлы стили, инлайново писать стили в компоненте или через js. Учитывая, что мне нужен был еще server side rendering, то я решил попробовать использовать реализацию стилей через js и выбрал для этого библиотеку react.jss. В реализации простых стилей вопросов к данной библиотеке нет, но при выборе библиотеки я не учел, что мне еще будет необходимо работать с медиазапросами в css. В данной библиотеки работы с медиазапросами я не нашел, все решения сводятся к использованию готовых решений, которые отслеживают ширину окна и позволяют определять тип устройства. Для меня это ни есть хорошо, потому что отслеживание ширины окна через js создает дополнительную нагрузку на процессор и является более энергоемкой чем через css. Но учитывая, что весь код для стилей написан на js, то использование его еще и для отслеживания ширины экрана считаю возможным, поэтому для решения данного вопроса воспользуюсь одним из пакетов для npm для отслеживания ширины экрана.
Вывод
В этой статьей мною было разобраны проблемы, с которыми я столкнулся во время реализации своего блога. Этой статьей я хочу показать, что ошибаться в программировании — это нормально, и что любые проблемы с кодом решаемы. Давайте вспомним, какие проблемы и их решения я описал в данной статье: ошибка выбора готового решения, что в итоге все-равно придется все свое по внешнему виду; проблема перехода между страницами на сайте; создание алиасов, способ хранения и отправки токенов на бекенд.
Больше статей в моем блоге. Спасибо, что дочитали и до новых встреч в следующих статьях.
