Когда я искал свою первую работу, я создал пет-проект. Сейчас я работал фронтенд-разработчиком, и после всего этого могу дать несколько советов для вашего проекта.
Эта статья предназначена только для начинающих разработчиков, которые хотят улучшить свои проекты. Некоторые советы могут оказаться бесполезными для кого-то. Это только мое мнение
№1 / без библиотеки
В своем пет-проекте я использовал несколько библиотек для сложных случаев. Но в своем продакшне мы не используем никаких библиотек типа слайдера, прелоадера и т.д. Потому что могут возникнуть какие-то ошибки из-за конфликта версий или других подводных камней. В общем, хочу сказать, что не стоит использовать либы, если вы понимаете, что можете решить это по-своему.
Конечно, мы не можем заменить фундаментальные библиотеки, такие как React, Redux, Axios и т. д. Я имею в виду популярные и решающие фундаментальные задачи разработки вашего проекта или созданные для автоматизации рутинной работы.
# 2 / подумайте о программах чтения с экрана
Когда вы создаете свой пет-проект, вы всегда должны думать о людях с ограниченными возможностями. Программа чтения экрана может быть программой, считывающей текст с экрана. В целом, многие младшие разработчики внешнего интерфейса понимают, что вы должны связать теги input и label. Но почему? Потому что тег label похож на ссылку на ввод, который вы связываете с атрибутом for. Но если вы проверите свой ввод с помощью программы чтения с экрана, вы можете обнаружить некоторые проблемы.
Кстати, неважно, будете ли вы оборачивать метку в ввод или наоборот. Но есть некоторые отличия в поведении — если метка вне ввода — ее можно разместить везде и ссылка на ввод тоже будет работать.
Что не так с этим кодом? Ничего. Но скринридер так не думает. Человек, использующий программу чтения с экрана, услышит: "Найди что-нибудь‹›Найди точку-точку-точку". Думаю, вы уже понимаете, почему это так — потому что программа чтения с экрана читает placeholder.Как это исправить?
После этого программа чтения с экрана будет игнорировать Найти…, потому что мы добавили атрибут aria-*. Это небольшой совет, но он может улучшить ваш пользовательский интерфейс. Вообще я рекомендую использовать атрибуты aria-* и подумать об особых случаях (например, как скрыть элемент от программы чтения с экрана).
Считыватель экрана о ценности функциональности? Если мы добавим атрибут к кнопке — это о функциональности, иначе — ценность.
#3 / все константы в одном файле
Представьте, что у вас есть слово, которое повторяется много раз, например, Amazon на их сайте. Как видите, Амазонка повторяется 28 раз! Сначала все в порядке, но вдруг вам нужно изменить Amazon на AMAZON. Да, вы можете использовать Изменить все вхождения в VS Code или любые другие функции в вашей IDE, но если вам нужно выполнять другие сложные операции, вы должны работать с одним входным экземпляром.
После этого вы можете импортировать нужную вам константу, и если вы измените основной экземпляр — вы измените все повторения в своем приложении.
#4 / объединить все цвета в одной функции
Только для шаблона CSS-IN-JS.
Как я уже сказал, лучше всего иметь один главный экземпляр. И еще о цветах.
В цветах мы должны добавлять только цвета по принципу «название цвета — код цвета». В semantic «сущность — colors.colorYouWant». В использовании это выглядит так:
# 5 / Компоненты презентации и контейнера
Разделите свою логику на компоненты контейнера и представления. Мы используем компонент контейнера, когда хотим реализовать какие-либо побочные эффекты, сохранить/обновить локальное состояние и вообще, когда хотим отделить логику приложения от пользовательского интерфейса. Мы используем компонент презентациидля рендеринга, другими словами, для пользовательского интерфейса.
Это пример, который показывает, как правильно разделить логику компонентов.
#6 / единый стиль для коммитов
Когда вы хотите сделать коммит, вы должны написать сообщение коммита. Например, если вы создали компонент нижнего колонтитула, вы выполняете следующие операции:
git add . git commit -m 'add a footer'
Что вы думаете об этом? Хорошо? Дано представьте, что ваша работа требует более 10 коммитов. Я имею в виду, что иногда можно сделать много коммитов и сделать коммиты правильно в одном стиле.
Как видите, я использую определенные флаги для имен коммитов.
--refactor / code refactoring --style / added/fixed styles --feature / added new functionality
Я рекомендую создавать флаги, которые «удобны» для вас. Под «удобным» я подразумеваю флаги, которые точно описывают ваши действия. Обычно я использую эти флаги:
Но вы можете сделать свои собственные флаги.
Заключение.
Я написал 6 советов для вашего проекта и это далеко не все, чем я хочу с вами поделиться. Очень надеюсь, что эти советы вам пригодятся. Я планирую продолжить эту статью и добавить новые советы, чтобы вы могли улучшить свой пет-проект!
Спасибо за чтение!
