Во время кодирования очень важно выработать хорошие привычки и механизмы, чтобы не допустить неожиданных ошибок. Чем больше у нас опыта, тем эффективнее мы становимся в этой области. Инженеры ежедневно предоставляют тонны кода, поэтому следование некоторым хорошо устоявшимся шаблонам важнее, чем пытаться проявить фантазию, используя этот последний крутой трюк, о котором мы только что прочитали в Твиттере. В конце концов, наша главная цель - предоставить функциональное и надежное программное обеспечение, верно?
Шумиха вокруг разработки JavaScript и Frontend
К сожалению, это заболевание действительно распространено среди разработчиков JavaScript, особенно в последние 3-4 года. Язык быстро развивается, новые технологии появляются каждый день, тенденции меняются то и дело и т. Д. Интерфейсному разработчику действительно легко разрушить свои старые добрые привычки, пытаясь быстро усвоить и внедрить столько новых интересных вещей.
Типичная ошибка в приложениях ReactJS
Так что же здесь? Это очень простая ошибка, которую многие даже опытные разработчики фронтендов делали хотя бы раз. Давайте погрузимся в ReactJS.
Мы все используем логический оператор И для рендеринга разметки, верно? Конечно. Это действительно удобно и заставляет выглядеть умнее 😉. Хорошо, мы также пишем немного меньше JSX-кода в нашем компоненте, что действительно приятно. Типичный пример:
Это работает, потому что в JSX true && expression оценивается как expression:
Хорошо, это было легко. Иногда это может показаться немного менее читаемым, особенно когда выражения там становятся более сложными, но в целом он работает нормально.
Все идет нормально. Давайте сделаем его более острым. Сколько раз вы это видели?
Это даст вам большой жирный 0 и ничего больше, поскольку items.length не оценивается как boolean. Вы ведь видели это уродливое 0 раньше, верно? Бьюсь об заклад, у тебя есть.
Это действительно распространенная ошибка, и на самом деле даже весьма опытные разработчики попадают в эту ловушку, какой бы простой она ни казалась. Почему? Потому что их устоявшиеся модели и привычки не соблюдались.
Некоторые решения
Мы можем использовать Boolean как функцию для решения этой проблемы:
Мы можем использовать двойной восклицательный знак, чтобы принудительно превратить его в логическое значение:
Мы можем использовать мертвое простое сравнение с 0:
Мы можем использовать тернарный оператор:
Мы можем использовать чистую функцию для запуска некоторой логики и рендеринга разметки, особенно если логика становится еще более сложной:
Мы даже можем использовать логику if...else... в нашей чистой функции, чтобы еще раз различать эти 2 случая:
Так много вариантов, но какой лучший? Хммм, у меня нет ответа на этот вопрос, но я уверен, что лучший из них - тот, который выглядит более читабельным для ваших глаз, избавляет вас от этих уродливых 0 и поможет вам быстро понять, что происходит, когда вы вернетесь через 2 или 3 месяца.
Наверное, поэтому многие опытные ребята, как я показал, предпочитают последний. Это может показаться скучным шаблоном, но это вполне безопасный, не требующий пояснений и расширяемый шаблон.
У каждого разработчика свои предпочтения и хорошие привычки. Создавайте свои собственные и придерживайтесь их, чтобы предоставлять надежное, удобочитаемое и удобное в обслуживании программное обеспечение. Ваше здоровье!!!
