Ошибка разработчиков привела к созданию какого приложения

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

Но как выглядит процесс создания мобильного приложения со стороны клиента? Можем ли мы уберечь вас от ошибок в разработке приложения, опираясь на свой опыт и знания? Надеемся, что так. 

Ошибки создания приложения, которые могут допустить клиенты на первом проекте

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

Ошибка № 1. Максимально наполнить приложение функциональностью и только по завершению всех работ уйти в релиз

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

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

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

Ошибка № 2. Вы очарованы своей идеей и не тестируете гипотезы

Почти все идеи, которыми с нами делятся наши потенциальные клиенты, прекрасны. Но для каждой идеи есть своё время и место. Перед разработкой нужно убедиться, что время вашей — пришло. Иначе можно не попасть в интересы целевой аудитории и потерять вложенные в проект деньги. 

Без тестирования гипотез вы рискуете создать ненужный пользователям продукт, который не окупит инвестиций 

Понять, что идея востребована и приложение принесёт бизнесу прибыль, поможет тестирование гипотез. Для этого нужно исследовать рынок, анализировать потребности целевой аудитории, выдвигать предположения, уточнять запросы, выпускать MVP и проверять реакцию пользователей — соответствует она выдвинутой гипотезе или нет.

Ошибка № 3. Выбирать тип оплаты, который не подходит проекту и не соответствует объёму работ

В разработке приложений есть три вида оплаты: 

• Fixed Price — когда клиент платит за продукт; 
• Time&Materials — когда клиент платит за выполненные задачи; 
• Retainer  — когда клиент платит за команду. 

Кажется, что дешевле заплатить за весь мобильный продукт, чем оплачивать работу специалистов позадачно или «нанимать» команду. Но для каждого вида работ выгоден свой тип оплаты. Fixed Price подходит небольшим типовым проектам, на которых нужно следовать техническому заданию. Если проект обширный, и вы планируете постепенно тестировать и внедрять новую функциональность, то подойдёт гибкая система оплаты Time&Materials. Модель Retainer будет выгодна для работы над масштабным проектом с большим количеством интеграций, сервисов и широким спектром задач, оценить которые по отдельности трудно. Также по ретейнеру удобно оплачивать работу ИТ-специалистов на аутстаффинге, которых обычно привлекают извне для ускорения работ по проекту.

Представьте, что вам нужно сделать уборку помещения после вечеринки. Для этого вы обращаетесь в клининговую компанию. При разных моделях оплаты к уборке может быть несколько подходов:

Fixed Price — вы платите за уборку всей квартиры. Если загрязнения оказались серьёзнее, чем вы предполагали, то добавить их в смету не получится. Придётся или оставить всё, как договаривались, или заключать с клинингом новый договор, чтобы завершить уборку. 

T&M — вы разделяете уборку квартиры на отдельные задачи (почистить ковёр, помыть окна, выбросить мусор) и клининг оценивает в часах, сколько времени займёт каждое действие. Если во время уборки появляются дополнительные задачи, то вы добавляете их в бэклог и платите клинингу за время, которое ушло на уборку.

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

Вадим Фингеров, 
руководитель отдела продаж в «Лайв Тайпинге»

Какая модель оплаты подходит вашему проекту? Напишите или позвоните +7 495 204-35-03 нам, и мы поможем вам сориентироваться в стоимости и сроках разработки вашего приложения.

Ошибка № 4. Пренебрегать тестированием 

У разработчиков есть примета: сэкономишь на тестировании — доплатишь при разработке. Чтобы она не сбылась, мало трижды плюнуть через левое плечо — нужно закладывать бюджет на тестировщика, который проверит приложение на наличие багов.

Ошибка №5. Недооценивать важность маркетинга

Сейчас один только App Store предлагает более двух миллионов приложений. Как среди этого океана цветных иконок пользователь найдёт ваше? Только с помощью продвижения. Интересные проекты, у которых нет бюджета на маркетинг, не попадают в поле зрения целевой аудитории и остаются без финансовой поддержки.

В первые годы работы мы создавали платформу, которая помогала выбрать, забронировать и оплатить летний языковой лагерь за рубежом. Такой букинг в сфере образования. У клиента было всё: попадание в боли целевой аудитории, минимум конкурентов, исправно работающая система, понятный UX/UI, — но клиент не закладывал бюджет на маркетинг. Запуск платформы прошёл без рекламы. О сервисе никто не узнал. Раскрутить его своими силами не удалось, и деньги, вложенные в разработку проекта, сгорели

Роман Палачёв, 
менеджер проектов в «Лайв Тайпинге»

Ошибка № 6. Вы оставляете приложение без поддержки

В сентябре вышла 15-ая версия iOS, и вместе с ней у компании Apple появились новые требования к приложениям. Одно из них — дать пользователю возможность навсегда удалить свой аккаунт из любого приложения. Срок исполнения — 31 января 2022 года. После этой даты Apple удалил из магазина приложения, которые не успели обновиться. 

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

Если у вас есть проект, о котором никто не заботится, — напишите нам. Мы вдохнем в него новую жизнь и будем развивать и дорабатывать ваше приложение, как родное.

Риски при разработке мобильного приложения

Когда мы говорим про риски на проекте, мы не имеем в виду, что собираемся идти ва-банк и надеяться на счастливый исход, реализуя безумную идею. Мы говорим, что мобильная разработка наполнена рисками — возможными опасностями, которые нужно предотвратить раньше, чем они произойдут. Чтобы это сделать, придётся узнать врага в лицо. Знакомство не из приятных, поэтому мы пережили эту встречу за вас и сделали из неё некоторые выводы.

Опасности, которые сопровождают создание мобильных приложений:

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

2. Сложная документация. Громоздкое ТЗ, написанное на несколько сотен страниц, в котором невозможно быстро найти нужную информацию усложняет общение между разработчиками и увеличивает время создания приложения. Чтобы этого не допустить, мы создаём документацию, которая решает точечные задачи.

3. Нарушение в работе интеграций. Интеграции — это сторонние сервисы, которые подключены к вашему мобильному приложению для сопровождения его работы: платёжные шлюзы, клиентские базы, смс-оповещения. За них отвечают компании-интеграторы. Если на их стороне происходит ошибка, то нам остаётся только ждать.  

4. Нарушение гайдлайнов App Store и Google Play. У сторов есть чёткие критерии того, как должно выглядеть и работать мобильное приложение. Если эти гайдлайны нарушить, то приложение не пройдёт проверку в сторе и будет возвращено на доработку. Степень опасности зависит от того, насколько серьёзной была причина возврата. Одно дело, если рецензенты посчитали, что скриншоты не подходят по содержанию приложения, а другое — если приложение крашится на старте. Если хотите узнать больше о том, как проверяют приложение и что может помешать релизу, — читайте наши статьи про публикацию приложений в App Store и Google Play. 

Как снизить риски при разработке мобильного приложения и избежать типичных ошибок

Чтобы создать приложение, не натыкаясь на чужие грабли, нужно очень хорошо эти грабли знать. Если мобильная разработка для вас новая сфера, то лучше найти команду, которая создаёт проекты не первый год и у которой есть релевантный опыт. 
Если вы увидели таких разработчиков в нас, то, во-первых, мы очень этому рады, а во-вторых, вот наш номер — +7 495 204-35-03 звоните или пишите нам, и мы поможем вам сделать проект, не делая ошибок.

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

Сегодня вы узнаете о нескольких игровых багах, которые в итоге стали особенностями.

GTA и Race’n’Chase

Серия игр Grand Theft Auto обязана своим появлением невышедшей игре Race’n’Chase. Под таким названиям компания DMA Design хотела выпустить интересный экшен с видом сверху. Выполнять миссии в нем, по задумке, можно было как за преступников, так и за полицию, а по городскому пространству можно было и ходить, и ездить на авто.

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

Street Fighter II: комбо

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

Считается, что в студии, выпускавшей игру, о баге знали. Один из продюсеров заметил проблему на бонусном уровне. Однако возможность делать комбо оставили, считая, что ее никто не заметит. Забавно, но фанаты файтингов быстро все обнаружили и посчитали, что это не ошибка, а новая возможность. После этого компания Capcom выпустила рекламу с комбо. Позже этим стали пользоваться и другие студии, добавляя в свои файтинги схожие возможности.

Quake: Стрейф-джамп и рокет-джамп

Известный сегодня всем шутер Quake появился еще в 1996 году. Он сразу стал культовой игрой, которая и по сей день считается классикой шутеров.

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

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

Team Fortress: шпионаж

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

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

Super Mario Bros: высокие прыжки от стен

Тот самый Марио имел множество способностей, но на самом деле не все они были запланированы сначала. Это касается и возможности отталкиваться от вертикальных поверхностей, чтобы сделать еще более высокий прыжок. Это баг, который случайно оказался в версии релиза. Разработчики некоторое время были в шоке, но внезапно увидели положительные отзывы игроков.

Поэтому «ошибку» решили оставить и даже улучшить уже в следующей версии игры.

Space Invaders: растущая сложность уровней

Когда игрок проходит Space Invaders, с каждым уровнем сложность игры возрастает. Звучит очевидно, ведь это свойственно практически каждой современной игры. Моду на увеличение сложности ввела именно эта аркада с кораблями, которые игроки должны были уничтожать, пока те спускались сверху.

Невероятно, но в изначальной концепции увеличение сложности разработчики не закладывали. Дело в том, что процессоры платформ, на которых играли в Space Invaders, ускоряли объекты, когда их количество уменьшалось. Таким образом, суть популярности игры была вызвана обычной непредусмотрительностью.

Minecraft: криперы

Когда в мире игры наступает ночь, выходят разные монстры: криперы — жуткие высокие гуманоиды без рук и с пустыми глазницами. Популярность среди игроков у криперов невероятная. Но и они появились из обычной ошибки создателя Minecraft.

Дело в том, что Маркус Перссон попросту спутал параметры длины и высоты, когда рисовал модель обычной свиньи. Но в игру криперы попали все же не в качестве бага, а по его собственному усмотрению, так как результатом он был впечатлен.

Tomb Raider: формы Лары Крофт

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

Разработчики изначально к такой идее не стремились. Все произошло случайно, когда один из разработчиков увеличил размер ее груди в несколько раз. Изображения внезапно попали к издателю, которому результат безумно понравился. Именно он настоял на этой версии, несмотря на то, что дизайнер Тоби Гард не желал создавать такую героиню, считая, что такой бюст не сочетается с образом независимой и отважной Лары Крофт.

Больше интересных статей читайте в моём блоге

Ошибки разработки приложений распространены, особенно для начинающих. Создание нового приложения может быть захватывающим. К сожалению, без надлежащих знаний, навыков и инструментов это может разочаровать и обескуражить.
Ошибки обязательно будут. К счастью, вы можете избежать тех, которые имеют значительные или серьезные последствия.
Создание приложения может быть дорогостоящим, если допущены серьезные ошибки. Помните, что эти ошибки могут иметь далеко идущие последствия. Единственная ошибка может привести к пустой трате ресурсов и повлиять на восприятие бренда.
Мы верим, что вы сможете избежать серьезных ошибок. Вот почему в этой статье мы рассмотрим некоторые часто совершаемые ошибки, которых следует избегать. Начнем.

Недостаточное исследование

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

Недостаточное тестирование

Одна из самых больших ошибок разработки приложений — запуск финального приложения без надлежащего тестирования.
Всегда рассматривайте возможность тестирования разных версий вашего приложения на разных платформах, чтобы убедиться в его жизнеспособности.
Несмотря на то, что у тестирования приложений есть свои проблемы, вы можете заставить его работать, если вы: Внутренние эксперты по тестированию могут проявлять предвзятость и упускать важные проблемы. Сторонние эксперты обеспечивают объективную и надежную обратную связь.
Одним из аспектов тестирования приложений является использование минимально жизнеспособного продукта (MVP). MVP — это модель вашего приложения, которая имеет только необходимые функции. Вы можете потерять до 62% пользователей вашего приложения, если ваше приложение будет работать некорректно. MVP позволяет вам тестировать производительность вашего приложения, исправлять ошибки и исправлять логические несоответствия.
Вы можете включить дополнительные функции в свой MVP, как только подтвердите, что функции работают без сбоев.

Плохое финансовое планирование.

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

Плохой дизайн UX/UI

42% людей, скачавших приложение, удалят его, если у него плохая сборка UI/UX. Полезный пользовательский интерфейс и дизайн UX обеспечивают пользователям релевантное и значимое взаимодействие с вашим приложением.
Вы можете разработать приложение с уникальными и полезными функциями. К сожалению, большинство разработчиков включают ненужные функции. Эти функции снижают производительность приложения и мешают работе пользователей.
Включите соответствующие функции, такие как навигация, главное меню, параметры поиска и т. д. После этого включите дополнительные функции при выпуске обновлений.
Помните, что ненужные функции снижают производительность приложения. Ваше приложение становится уязвимым для сбоев, ошибок и ошибок.
Они также требуют больше времени и денег для реализации. Кроме того, эти функции увеличивают размер приложения, из-за чего пользователи, скорее всего, удалят его, когда памяти телефона станет мало.
В Andromo мы создаем приложения с привлекательным дизайном UX/UI.

Пытаюсь скопировать ваш сайт.

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

Плохая связь

Создание приложения похоже на запуск машины. Различные части устройства должны работать в унисон, чтобы оно работало. Если одна часть выходит из строя или посылает неправильный сигнал, машина скомпрометирована.
Эффективное общение позволяет вам выражать свои идеи, требования и цели вашей команде.
Это также позволяет команде сообщать о трудностях и находить решения. Делитесь своим прогрессом и идеями во время ежедневных или еженедельных встреч.

Неэффективная кроссплатформенная стратегия

Создание приложения для разных платформ — распространенная ошибка разработчиков приложений. Хотя можно создать Android и iOS, это два разных предприятия.
Такой шаг может вызвать задержки и удвоить ваши затраты на разработку.
Вы можете создать приложение как для Android, так и для iOS, используя наш современный конструктор приложений Andromo. Мы предлагаем выгодные цены и сокращаем ваши сроки.

Наем неквалифицированной команды разработчиков

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

Мало или нет обновлений

Разработка приложения не заканчивается после публикации и запуска приложения. Тебе нужно:
1. Улучшить совместимость
2. Интегрируйте новые технологии.
3. Избавьтесь от ошибок.
4. Создайте максимальный пользовательский опыт и многое другое.
Выберите разработчика приложений, который предлагает услуги по обслуживанию и обновления в течение долгого времени после завершения разработки приложения.
Делайте регулярные обновления, скажем, раз в месяц или несколько раз в месяц, в зависимости от потребностей ваших пользователей.

Заключение

Ошибки в разработке приложений лишают процесс создания приложений удовольствия. Создание приложений требует планирования, тестирования и коммуникации. Сократите количество этих ошибок, привлекая разработчика Andromo для создания своего приложения. Теперь, когда вы знаете, какие шаги нужно предпринять, наслаждайтесь созданием своего приложения.

Поскольку React становится все более и более популярным, все больше и больше React разработчиков сталкиваются с различными проблемами в процессе разработки.
В этой статье, мы обобщим некоторые распространенные ошибки в разработке React приложений, чтобы помочь вам их избежать.
Если вы только начинаете использовать React, рекомендуется внимательно ознакомиться с этой статьей. Если вы уже используете React для разработки проектов, также рекомендуется проверить и заполнить пробелы.

Прочитав эту статью, вы узнаете, как избежать эти 11 ошибок React:

• При рендеринге списка не используется key
• Изменение значения состояния прямым присваиванием
• Привязка значения состояния непосредственно к свойству value инпута
• Использование состояния сразу после выполнения setState
• Появление бесконечного цикла при использовании useState + useEffect
• Отсутствие очистки побочных эффектов в useEffect
• Неправильное использование логических операторов
• Тип пропсов компонента не типизирован
• Передача строк в качестве значений компонентам
• Имя компонента не начинается с заглавной буквы
• Неверная привязка события к элементу

Ошибка: При рендеринге списка не используется key

Проблема
Когда мы впервые изучали React, мы отображали список следующим образом:

const items = [
  { id: 1, value: 'item1' },
  { id: 2, value: 'item2' },
  { id: 3, value: 'item3' },
  { id: 4, value: 'item4' },
  { id: 5, value: 'item5' }
];

const listItems = items.map((item) => {
  return <li>{item.value}</li>
});
После рендеринга консоль выдаст предупреждение, что для элементов списка необходимо указать ключ.

Решение

Вам просто нужно последовать этой подсказке и добавить key к каждому элементу:
const items = [
  { id: 1, value: ‘item1’ },
  { id: 2, value: ‘item2’ },
  { id: 3, value: ‘item3’ },
  { id: 4, value: ‘item4’ },
  { id: 5, value: ‘item5’ }
];

const listItems = items.map((item) => {
  return <li key={item.id}>{item.value}</li>
});


key помогает React определить, какие элементы были изменены, например, добавлены или удалены. Поэтому нам нужно установить уникальное значение ключа для каждого элемента в массиве.

Для значения ключа лучше всего установить уникальное значение. В приведенном выше примере используется id. Можно использовать индекс массива, но такой подход не рекомендуется.

Уникальный ключ помогает React следить за изменениями списка — какой элемент удалился или переместился.


Ошибка: Изменение значения состояния прямым присваиванием
Проблема

В React нельзя назначать состояние и изменять напрямую, иначе это вызовет проблемы.
// классовый компонент

handleChange = () => {
   this.state.name = "John";
};
В этот момент будет выдано предупреждение не изменять состояние напрямую, а использовать setState().

Решение

Классовые компоненты могут быть изменены с помощью setState(), а функциональные компоненты могут быть изменены с помощью useState():
// Классовые компоненты: используйте setState()
this.setState({ name: "John" });

// Функциональные компоненты：используйте useState()
const [name, setName] = useState("");
setName("John");
Ошибка: Привязка значения состояния непосредственно к свойству value инпута
Проблема

Когда мы напрямую привязываем значение состояния к свойству value инпута, мы обнаружим, что независимо от того, что мы вводим в поле ввода, содержимое поля ввода не изменится.
export default function App() {
  const [count, setCount] = useState(0);
  return <input type="text" value={count} />;
}
Это связано с тем, что мы используем переменную состояния в качестве значения по умолчанию для присвоения значения <input>, а состояние в функциональном компоненте может быть изменено только функцией set*, возвращаемым useState. Таким образом, решение также очень простое, просто используйте функцию set* при изменении. Подробнее о том как работать с инпутом в React можно прочитать в этой статье.

Решение

Просто привяжите событие onChange к <input> и измените его, вызвав setCount:
export default function App() {
  const [count, setCount] = useState(0);
  const handleChange= (event) => setCount(event.target.value);

  return <input type="text" value={count} onChange={handleChange} />;
}
Ошибка: Использование состояния сразу после выполнения setState
Проблема

Когда мы изменяем данные через setState() и сразу же хотим получить новые данные, возникнет ситуация, что возвращаются старые данные:
// Классовые компоненты

// инициализация состояния
this.state = { name: "John" };

// обновление состояния
this.setState({ name: "Hello, John!" });
console.log(this.state.name); // => John
Это связано с тем, что setState() является асинхронным. Когда setState() выполняется, реальная операция обновления будет помещена в асинхронную очередь для выполнения, а код, который будет выполняться следующим (т.е. console.log в примере), выполняется синхронно, поэтому выводимое в консоль состояние не является последним значением.

Решение

Просто передайте последующую операцию, которая будет выполняться как функция, в качестве второго параметра setState(), эта функция обратного вызова будет выполнена после завершения обновления.
this.setState({ name: "Hello, John!" }, () => {
  console.log(this.state.name); // => Hello, John!
});
Теперь обновленное значение выводится правильно.


Ошибка: Появление бесконечного цикла при использовании useState + useEffect
Проблема

Когда мы напрямую вызываем метод set*(), возвращаемый useState() внутри useEffect(), и не устанавливаем второй параметр в useEffect(), мы столкнемся с бесконечным циклом:
export default function App() {
  const [count, setCount] = useState(0);
  useEffect(() => {
    setCount(count + 1);
  });
  return <div className="App">{count}</div>;
}
После этого можно увидеть, что данные на странице обновляются, и функция useEffect() вызывается бесконечно, входя в состояние бесконечного цикла.

Решение

Это распространенная проблема неправильного использования useEffect(). useEffect() можно рассматривать как комбинацию трех функций жизненного цикла: componentDidMount, componentDidUpdate и componentWillUnmount в классовых компонентах. useEffect(effect, deps) принимает 2 аргумента:

effect функция, которая должна выполниться (побочный эффект)
deps массив зависимостей

При изменении массива deps выполняется функция эффекта. Чтобы изменить метод, вам нужно всего лишь передать [] в качестве второго аргумента useEffect() :
export default function App() {
  const [count, setCount] = useState(0);
  useEffect(() => {
    setCount(count + 1);
  }, []);

  return <div className="App">{count}</div>;
}


Приведем 4 случая использования useEffect:

Если второй параметр не передан: при обновлении любого состояния будет запущена функция эффекта useEffect.

useEffect(() => {
  setCount(count + 1);
});

Если второй параметр — это пустой массив: функция эффекта useEffect срабатывает только при монтировании и размонтировании.

useEffect(() => {
  setCount(count + 1);
}, []);

Если второй параметр представляет собой массив с одним значением: функция эффекта useEffect будет запускаться только при изменении значения.

useEffect(() => {
  setCount(count + 1);
}, [name]);

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

useEffect(() => {
  setCount(count + 1);
}, [name, age]);
Ошибка: Отсутствие очистки побочных эффектов в useEffect
Проблема

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

Решение

Из функции эффекта useEffect() может быть возвращена функция очистки, которая аналогична роли метода жизненного цикла componentWillUnmount():
useEffect(() => {
  // ...
  return () => clearInterval(id);
}, [name, age]);
Ошибка: Неправильное использование логических операторов
Проблема

В синтаксисе JSX/TSX мы часто используем логические значения для управления отображаемыми элементами, и во многих случаях мы используем оператор && для обработки этой логики:
const count = 0;
const Comp = () => count && <h1>Chris1993</h1>;
Мы думаем, что в это время страница будет отображать пустой контент, но на самом деле на ней отобразится 0.

Решение

Причина в том, что ложное выражение приводит к тому, что элементы после && пропускаются, и будет возвращено значение ложного выражения. Поэтому нужно стараться написать условие оценки как можно более полным, не полагаясь на истинное и ложное логическое значение JavaScript для сравнения:
const count = 0;
const Comp = () => count > 0 && <h1>Chris1993</h1>;
Теперь страница будет отображать пустой контент, как и ожидается.


Ошибка: Типы просов компонента не типизированы
Проблема

Если компоненты, разработанные разными членами команды, не имеют четко определенных типов для просов, то для коллег будет не очевидно, как использовать компоненты, например:
const UserInfo = (props) => {
  return (
    <div>
      {props.name} : {props.age}
    </div>
  );
};
Решение

Определить типы пропсов компонента, используя TypeScript.

// Классовые компоненты
interface AppProps {
  value: string;
}
interface AppState {
  count: number;
}
class App extends React.Component<AppProps, AppStore> {
  // ...
}

// Функциональные компоненты
interface AppProps {
  value?: string;
}
const App: React.FC<AppProps> = ({ value = "", children }) => {
  //...
};

Без использования TypeScript типы пропсов могут быть определены с помощью propTypes.

const UserInfo = (props) => {
  return (
    <div>
      {props.name} : {props.age}
    </div>
  );
};
UserInfo.propTypes = {
  name: PropTypes.string.isRequired,
  age: PropTypes.number.isRequired,
};
Ошибка: Передача строк в качестве значений компонентам
Проблема

Так как React имеет шаблонный синтаксис, очень похожий на HTML, часто бывает так, что числа передаются напрямую компонентам в пропсы, что приводит к неожиданному результату:
<MyComp count="99"></MyComp>
Сравнение props.count === 99 в компоненте MyComp вернет false.

Решение

Правильный способ должен заключаться в использовании фигурных скобок для передачи пропсов:
<MyComp count={99}></MyComp>
Передача строковых просов будет выглядеть следующим образом:
<MyComp count={"99"}></MyComp>
Ошибка: Имя компонента не начинается с заглавной буквы
Проблема

Начинающие разработчики часто забывают называть свои компоненты с заглавной буквы. Компоненты, начинающиеся со строчной буквы в JSX/TSX, компилируются в элементы HTML, такие как <div /> для тегов HTML.
class myComponent extends React.component {}
Решение

Просто измените первую букву на заглавную:
class MyComponent extends React.component {}
Ошибка: Неверная привязка события к элементу в классовых компонентах
Проблема
import { Component } from "react";

export default class HelloComponent extends Component {
  constructor() {
    super();
    this.state = {
      name: "John",
    };
  }
  update() {
    this.setState({ name: "Hello John!" });
  }

  render() {
    return (
      <div>
        <button onClick={this.update}>update</button>
      </div>
    );
  }
}
При нажатии на кнопку update консоль сообщит об ошибке, что невозможно прочитать свойства undefined (чтение setState)

Решение

Это происходит потому, что this не привязан к тому контексту, который мы ожидаем. Есть несколько решений:

Привязать контекст в конструкторе при помощи метода bind

constructor() {
  super();
  this.state = {
    name: "John"
  };
  this.update = this.update.bind(this);
}

Использовать стрелочные функции

update = () => {
  this.setState({ name: "Hello John!" });
};

Привязать прямо в функции рендеринга

<button onClick={this.update.bind(this)}>update</button>

Использовать стрелочные функции в функции рендеринга (не рекомендуется, т.к. это создает новую функцию каждый раз при рендеринге компонента, что влияет на производительность)

<button onClick={() => this.update()}>update</button>

Что такое функция setInterval?

Функция setInterval() используется для многократного вызова функции или фрагмента кода через определенный промежуток времени.
Пример:

setInterval(() => {
  console.log('you can see me every 3 seconds')
}, 3000);
Единственный способ остановить setInterval — вызвать функцию clearInterval с идентификатором или закрыть окно.


Использование setInterval в React хуках
Мы можем использовать функцию setInterval в React, точно так же, как мы можем использовать в JavaScript.

В приведенном ниже примере мы используем функцию setInterval внутри хука useEffect.
// App.js

import React, { useEffect, useState } from "react";

export default function App() {
  const [seconds, setSeconds] = useState(1);

  useEffect(() => {
    const timer = setInterval(() => {
      setSeconds(seconds => seconds + 1);
    }, 1000);
    
    // очистка интервала
    return () => clearInterval(timer);
  });

  return (
    <div className="App">
      <h1>Number of seconds is {seconds}</h1>
    </div>
  );
}
Хук useEffect запускает функцию обратного вызова (колбэк) при подключении компонента к dom, что аналогично методу жизненного цикла componentDidMount в компонентах-классах.

Функция setInterval запускает метод setSeconds каждую секунду.

Внутри хука useEffect мы возвращаем функцию clearInterval с аргументом timer, так что функция setInterval останавливается при отключении компонента от dom, что аналогично методу componentWillUnmount.


Использование setInterval в классовых компонентах
В этом примере показано, как использовать setInterval в компонентах-классах.
// App.js

import React from "react";

class App extends React.Component {
  state = {
    seconds: 1
  };

  componentDidMount() {
    this.timer = setInterval(() => {
      this.setState({ seconds: this.state.seconds + 1 });
    }, 1000);
  }

  componentWillUnMount() {
    clearInterval(this.timer);
  }

  render() {
    return (
      <div className="App">
        <h1>Number of seconds is {this.state.seconds}</h1>
      </div>
    );
  }
}

export default App;
В приведенном выше примере мы увеличиваем свойство this.state.seconds с помощью функции setInterval().