JavaScript *

Доброго времени суток, Хабр!

Все reactjs разработчики, кто имеет дело с интерактивностью между бэком и фронтом рано или поздно встречаются, или встречались, или встретятся со следующей ошибкой:


Если дословно, то получится так:

Предупреждение. Невозможно выполнить обновление состояния React для неустановленного компонента. Это не операция, но она указывает на утечку памяти в вашем приложении. Чтобы исправить, отмените все подписки и асинхронные задачи в функции очистки useEffect.

На самом деле все достаточно просто, нужно всего лишь обратить внимание на следующие словосочетания:

1. Невозможно выполнить обновление состояния
2. неустановленного компонента;
3. отмените все подписки и асинхронные задачи
4. очистки useEffect

В основе хуки. GO в под кат!

Мобильное приложение может выступать в роли «рабочего места» сотрудника, при этом бывает необходима передача географических координат и прочих данных. При кроссплатформенной разработке приложений на iOS и Android для этой задачи зачастую используют фреймворки, такие как Flutter или React Native. В этой статье мы рассказываем об особенностях работы с геолокацией в React Native на примере нашего кейса.

Всем привет. В преддверии старта курса «Fullstack разработчик JavaScript» подготовили для вас перевод интересного материала.

---

TL;DR: Веб-разработка дело трудное независимо от того, создаете вы свои собственные компоненты, используете дизайн-системы, реализуете поддержку различных браузеров, обеспечиваете доступность или добавляете сторонние зависимости. Lion стремится облегчить вашу жизнь, беря на себя реализацию полнофункциональных, доступных, производительных и не привязанных к определенному фреймворку компонентов. Загляните в репозиторий ing-bank/lion.

Возможно, некоторые из вас уже знают, что у ING долгая и богатая история создания веб-компонентов, начиная с библиотеки Polymer и заканчивая недавней LitElement.

Перевод статьи подготовлен в преддверии старта курса «Разработчик Node.js».

---

У современных разработчиков есть много альтернатив, когда речь заходит о создании веб-сервисов и других серверных приложений. Node стал крайне популярным выбором, однако многие программисты предпочитают более надежный язык, чем JavaScript, особенно те, кто пришел из современных объектно-ориентированных языков, например, таких как C#, C++ или Java. Если TypeScript просто хорошо подходит NodeJS , то фреймворк NestJS выводит его на совершенно новый уровень, предоставляя современные инструменты бэкенд-разработчику для создания долговечных и высокопроизводительных приложений с использованием компонентов, провайдеров, модулей и других полезных высокоуровневых абстракций.

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

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



Код веб-страницы традиционно состоит из трех разделов, каждый из которых выполняет свои обязанности: HTML-код определяет структуру и семантику, CSS-код определяет внешний вид, а JavaScript-код определяет его поведение. В командах с участием дизайнеров, HTML / CSS разработчиков и JavaScript-разработчиков это разделение получается естественно: дизайнеры определяют визуальные элементы и пользовательский интерфейс, разработчики HTML и CSS размещают эти визуальные элементы на странице в браузере, а JavaScript-разработчики добавляют взаимодействие с пользователем, чтобы связать все вместе и «заставить это работать». Каждый может работать над своими задачами, не вмешиваясь в код остальных двух категорий разработчиков. Но все это справедливо для так называемого «старого стиля».

Всем привет! Сегодня я попробую поэкспериментировать с Dependency Injection на чистом JavaScript. Тех кто не в курсе, что это за дичь и как ее готовить, приглашаю ознакомиться. Ну а у тех кто в курсе будет повод написать важный и полезный комментарий. Итак, погнали…

Как давно вы платили на веб-сайте в один клик с помощью Google Pay, Apple Pay или заранее заданной в браузере картой?

У меня такое получается редко.

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

Это не очень удобно. Особенно когда знаешь об альтернативе: в последние пару лет стандарт Payment Request API позволяет легко решать эту проблему в современных браузерах.

Давайте разберемся, почему его не используют, и попробуем упростить работу с ним.

Контекст и предыстория

Мне 62. Года три назад решил попробовать написать достаточно сложную систему, до этого было только 20 строк на бэйсике в 1981 г., когда нам на 5 курсе радио-факультета (НГТУ, ранее НЭТИ) воткнули 3 месяца информатики. Профессионалом принято считать того, кто предметом владеет и на нем зарабатывает, так что по факту я — новичок.

С другой стороны, я почти всю жизнь занимался относящимися к музыке алгоритмами, застал процесс развития и железа, и ПО и по мере сил участвовал в нем. В 1978 разработал и собрал синтезатор а-ля Mini-Moog (полагаю, 1-й за Уралом), разработал и выпускал 1-ю в СССР звуковую карту с синтезатором для Агат7(9) — советский аналог Apple II, проектировал модуль FM-синтеза для одного из заводов, сотрудничал с Cakewalk (США), PGMusic (Канада), PowerFX (Швеция) — чаще по схеме: «идеи и воплощение от нас, бюджет — от них», участвовал в международных музыкальных выставках MusikMesse (Германия), NAMM (США) и пр.

В преддверии старта курса «React.js разработчик» подготовили перевод полезного материала.

---

Как масштабируется front-end вашего приложения? Как сделать так, чтобы ваш код можно было поддерживать полгода спустя?

В 2015 году Redux штурмом взял мир front-end разработки и зарекомендовал себя как стандарт выйдя за рамки React.

В компании, в которой я работаю, недавно закончился рефакторинг большой кодовой базы на React, где мы внедрили redux вместо reflux.

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

Кодовой базе уже больше двух лет и reflux был в ней с самого начала. Нам пришлось менять код, сильно завязанный на компонентах React, который никто не трогал больше года.
Опираясь опыт от проделанной работы, я создал этот репозиторий, который поможет объяснить наш подход к организации кода на redux.

В 2020 году фронтенд-фреймворки стали лучше, эффективнее и быстрее. Но, даже учитывая это, рендеринг больших списков без «замораживания» браузера всё ещё может оказаться сложной задачей даже для самых быстрых из существующих фреймворков.

Это — один из тех случаев, когда «фреймворк является быстрым, а код — медленным».



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

Автор статьи, перевод которой мы сегодня публикуем, хочет исследовать существующие способы вывода больших списков на веб-страницах и поговорить о сферах их применения.

Журналисты ежедневной американской деловой газеты «Уолл-стрит джорнэл» пишут, что «в этом финансовом эксперименте не пострадало ни одно животное, но эго некоторых человеческих существ было сильно уязвлено».


Вместо обезьяны всё сделает JavaScript

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

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

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

В статье приведу код эксперимента и дам ссылку на гитхаб.

Давным-давно я написал статью о работе с EventManager в Angular. В ней я рассказал, как можно сохранить привычный нам синтаксис подписок на события, при этом избежав лишних запусков проверки изменений на частых и чувствительных событиях.

Однако описанный мною метод громоздкий и сложный для восприятия. Пришло время переписать фильтрацию на декораторы.

В этой статье я покажу как разработать удивительно информативные и удобные дашборды для любого Node JS приложения, опишу связку Prometheus с Grafana и дам шаблоны кода, чтобы вы могли использовать полученные знания для решения своих задач.

Большая часть статьи никак не ориентированна именно на Node JS разработчиков и может быть полезна вне зависимости от языка программирования.

Ссылка на Github репозиторий с кодом к статье — https://github.com/pavlovdog/grafana-prometheus-node-js-example

Слышали об использовании ES6-модулей в браузере? Собственно — это обычные ES6-модули. Только применяются они в коде, предназначенном для браузеров.

Начнём этот материал с вопроса. ES2015-модуль increment содержит следующий код:

// increment.js
let counter = 0;
counter++;

export default counter;

В другом модуле, который мы назовём consumer, вышеприведённый модуль импортируется 2 раза:

// consumer.js
import counter1 from './increment';
import counter2 from './increment';

counter1; // => ???
counter2; // => ???

А теперь, собственно, вопрос. Что попадёт в переменные counter1 и counter2 после выполнения модуля consumer?



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

Любая достаточно развитая технология неотличима от магии.
Артур Кларк
 
— Я больше не хочу быть сравнением… Сделайте меня метафорой.
Чайна Мьевиль

Работа над большим проектом похожа на метроидванию. Решая частные проблемы, мы открываем новые возможности. Со временем, эти возможности крепнут, соединяются с другими возможностями и это позволяет решать застарелые, куда более важные и сложные проблемы новым, совершенно неожиданным способом. У меня есть хороший пример на эту тему. И я хочу о нём рассказать.

Мы долго готовили обновление Smartcalls – визуального редактора для исходящих звонков – и вот оно случилось. Сегодня под катом расскажем про UI/UX-изменения и залезем под капот деморежима, чтобы показать, как мы приручали JointJS.

Mithril.js — непопулярный инструмент для создания клиентских веб приложений. На Хабре практически нет публикаций по этой теме. В этой заметке я хочу показать, как можно сделать небольшое приложение на Mithril. Приложение будем делать по мотивам вот этой публикации (перевод)

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

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

Тому, кто разбирается в веб-разработке, будет несложно создать новое расширение для браузера. Сейчас большинство самых популярных браузеров поддерживает стандартную систему разработки, которая использует в основном только JavaScript, HTML и CSS, — WebExtensions.

Человеку, который никогда раньше не создавал дополнение для браузера на основе WebExtensions, может быть тяжело сразу понять, из каких основных частей оно должно состоять и что может делать. В сети Интернет есть много информации об этой системе, но для того, чтобы создать для себя общую картину, придётся потратить много времени. Эта статья поможет быстро разобраться в устройстве системы WebExtensions и покажет, как лучше ориентироваться в документации к её API. Здесь описывается расширение для браузера Firefox, поэтому почти вся информация, используемая в статье, взята с сайта MDN. Но статья будет полезна и тем, кто хочет создать расширение для других браузеров, поддерживающих WebExtensions, — в первую очередь для Google Chrome и Chromium.

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