Программирование — это искусство находить золотую середину между стремлением к идеальному коду и реальными ограничениями времени.
Нельзя написать руководство, которое покрывало бы все вопросы написания кода, но мы постараемся обсудить общие рекомендации направленные на улучшение качества вашего кода.
Имена переменных должны описывать, что хранится в переменной или в свойстве, что функция или метод делают.
В одном из моих недавних проектов столкнулся с проблемой: в большом приложении, над которым работают десятки разработчиков, необходимо было обеспечить единообразный порядок импортов. Несмотря на то, что команда договорилась о том, в каком порядке импортировать модули, компоненты, директривы, миксины и прочее, в старом коде порядок импортов отличался, и его ручной рефакторинг оказался слишком трудоёмким и затратным по времени.
Хотя я немного разочаровался в web-движке PlayCanvas, после того как его апгрейды поломали мне первый диаблоид - для каких-то очень маленьких легковесных игр он остаётся достаточно хорош. Поэтому для разнообразия реанимировал аккаунт и немного погрузился в программирование на js, написав аркаду (с механикой что-то вроде специфического урезанного BattleCity, но на сфере), где инопланетный космический кораблик летает над некоей планеткой.
На тему мемоизации написано довольно много статей, и все они хорошо раскрывают суть. Но мне часто не хватало шпаргалки, которую можно отправить на вопрос «А как мемоизировать?». В статье речь пойдет исключительно о функциональных компонентах.
Функциональный компонент — это обычная JavaScript-функция, и часто при обсуждении, когда говорят «компонент рендерится», имеют в виду само выполнение этой функции.
При создании компонента, когда функция выполняется впервые, говорят, что компонент «рендерится». А когда в компоненте что-то изменилось, то говорят, что компонент «перерендеривается».
Недавно давно я смотрел ничем не примечательный техническое интервью и услышал фразу от интервьюируемого: «Ну можно написать свой useReducer или useState». Мне врезалась эта фраза в голову, ибо я никогда в серьез не задумывался как они работают под капотом и в исходниках особо не копался, максимум в типах. Из-за этого задача оказалась довольно сложной и интересной для меня ибо много получил много новой информации за довольно короткий срок и ее было сложно переварить и осознать.
Всем привет, меня зовут Илья, я работаю Frontend разработчиком в компании Бастион.
В данной статье я хочу затронуть такую интересную тему, как обновление бандла Capacitor-приложений (CodePush, live update и т.д).
Сталкивались ли Вы когда-нибудь с ситуацией, когда необходимо незначительно обновить мобильное приложение, написанное на Capacitor?
В данной статье осуществлен разбор многопользовательского телеграм чат бота на LLM, код которого опубликован в этом репозитории
Когда-то давным давно графический пользовательский интерфейс сменил консольный ввод. Казалось бы, проблему неудобства взаимодействия для неподготовленного пользователя мог бы решить псевдографический интерфейс, но есть фактор, который не все замечают
Привет, меня зовут Алёна, я senior фронтент-разработчик в отдела разработки ПО для розничного бизнеса в Райффайзенбанке. Недавно наша команда решила улучшить пользовательский опыт обработки ошибок запроса к бекенду и я решила комплексно исследовать эту тему и собрать воедино все лучшие практики.
Начтем с того, что при обработке ошибок Axios запросов существуют 4 ситуации, которые необходимо по-разному интерпретировать:
Запрос был обработан сервером и статус ответа сервера вне диапазона 2xx
Запрос был сделан, но ответ не был получен.
Ошибка возникла из-за неправильных настроек Axios.
При разработке веб-приложений не все задумываются о том, сколько памяти потребляет их код. О производительности наших сайтов мы вспоминаем гораздо чаще. К тому же не каждому разработчику интересно «экономить на спичках». Разве может наш код на языке JavaScript требовать много памяти? «Много» — это вообще сколько? 100 мегабайтов — это много?
Меня зовут Антон Непша. Я работаю в Сбере, разрабатываю сайт СберБанк Онлайн и веду Telegram-канал Антон Непша.js. Недавно я выступил на HolyJSЧитать полностью »
Привет, друзья!
В праздники я провел небольшое исследование представленных сегодня на рынке бесплатных инструментов с участием "искусственного интеллекта" для помощи в веб-разработке, результатами которого хочу с вами поделиться, авось кому-нибудь пригодится.
Обратите внимание, что я акцентировал внимание на бесплатных решениях для написания кода клиентской части веб-приложений.
Список протестированных инструментов:
Далее я подробнее расскажу о первых трех (Codeium, Devv, V0) и немного о двух следующих за ними (ChatGPT, GPT4All) решениях из представленных в списке, как наиболее "выдающихся" с моей точки зрения. Остальные сервисы (начиная с cursor и ниже) в той или иной степени похожи на codeium и `devv`, но показывают более плохие результаты генерации кода по запросу, исправления ошибок и документирования кода, а также менее удобны в использовании и иногда требуют дополнительных настроек, например, указания ключа OpenAI, установки лишних инструментов (тулкитов), являются условно бесплатными и т.п.
