Оглавление

Введение
1. Установка и начало работы
2. Redux
....2.1 createStore
....2.2 reducer()
....2.3 dispatch()
....2.4 actionCreator()
....2.5 Actions
....2.6 getState()
....2.7 subscribe()
....2.8 combineReducers()
....2.9 initialState
3. React-redux
....3.1 Provider
....3.2 mapStateToProps()
....3.3 mapDispatchToProps()
....3.4 connect()

Введение

Вот вы прочитали мою статью про React (если нет, то настоятельно рекомендую вам сделать это) и начали разрабатывать приложения на нём. Но что это? Вы замечаете, как с расширением вашего приложения становится всё сложнее следить за текущим состоянием, сложно следить за тем, когда и какие компоненты рендарятся, когда они не рендарятся и почему они не рендарятся, сложно следить за потоком изменяющихся данных. Для этого и есть библиотека Redux. Сам React хоть и лёгкий, но для комфортной разработки на нем нужно много чего изучить.

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



В моём случае, так как я много работаю с popper.js, я нашёл библиотеку tippy.js, написанную тем же разработчиком. Для меня такая библиотека выглядела как идеальное решение задачи. Библиотека tippy.js обладает обширным набором возможностей. С её помощью можно создавать и всплывающие подсказки (элементы tooltip), и многие другие элементы. Эти элементы можно настраивать с помощью тем, они быстры, строго типизированы, обеспечивают доступность контента и отличаются многими другими полезными возможностями.

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

Как знания нейропсихологии могут помочь программисту в стилизации кода? До того, как заняться программированием, я очень долго и глубоко изучал нейропсихологию. Впоследствии эти знания помогли мне добиться высоких результатов в разработке за короткий промежуток времени.

В этой статье я хочу поделиться своим опытом и подходом к стилизации кода. Мы рассмотрим стилизацию со стороны программирования, а затем немного коснемся нейропсихологии для более глубокого понимания самого процесса и степени его важности для разработчика. Последний год я работаю в компании Secreate, где занимаюсь разработкой мобильных приложений на фреймворке React Native, поэтому примеры кода, приведенные в этой статье, будут на языке Javascript. Знания, полученные из этой статьи, можно будет легко применить к любому языку программирования. В конце статьи вас ждут полезные примеры стилизации кода. Приятного чтения!

Что такое стилизация

Каждый программист имеет свое представление о code style. Для меня стилизация — это набор правил для оформления, таких как: отступы, пробелы, переносы, последовательность и так далее. Тем не менее, каждый программист оформляет свой код по-своему. Давайте рассмотрим несколько примеров такого оформления.

Импорты

Некоторые программисты пишут их так:

import {SomeClass} from ‘some/file’

Некоторые так:

import { SomeClass } from ‘some/file’

Еще можно встретить такое:

import {SomeClass, someFunction, someConst, AnotherClass и еще много чего в длинную строку} from ‘some/file’

Или такое:

import {
  SomeClass,
  somefunction,
  someConst,
  AnotherClass,
  и еще много чего в столбик
} from ‘some/file’

Объявление функций

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

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

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

Какой способ работы с DOM самый быстрый:

• Virtual DOM
• Tagged Template Literals
• Fine-Grained Observables

Многие разработчики полюбили лаконичный синтаксис и мощь директив Vue.js настолько, что даже пытаются использовать этот фреймворк не только в одностраничных приложениях. Сложно отказаться от использования реактивности, только потому, что вдруг понадобилось написать небольшой проект. Не возвращаться же к старому доброму jQuery или к чистому JS?!

Надо сказать, что во Vue.js (да и во многих других фреймворках) предусмотрен такой вариант его использования. Но все же он кажется слишком громоздким для такой простой работы, а функционал избыточным. И тут на помощь приходит Alpine.js.

Отметим некоторые особенности данного фреймворка:

1. Он весит очень мало! 7.2kB в сжатом виде.
2. Знакомый и простой синтаксис основанный на директивах.
3. Не использует виртуальный DOM
4. Подключения возможно как через CDN (по задумке авторов должно быть основным использованием), так и через npm.

Первая часть обзора была посвящена библиотекам Prototype.js и requirejs. Уже в процессе написания, возникла необходимость рассматривать не только библиотеки, которые существенно повлияли на современное состояние JavaScript, но и идеи, которые публиковались в статьях, прорабатывались в спецификациях, например: ajax, commonjs, универсальные/изоморфные веб-приложения.

Во времена повсеместной одержимости библиотеками и веб-фреймворками мы стали забывать радость от решения задач минимальными средствами. В этой статье, мы запилим веб-сервис на актуальную тему, используя ванильные Python и JavaScript, а также, задеплоим его в GitLab Pages. Быстро, минималистично, без лишних зависимостей, и максимально элегантно.

Вдохновившись видосом How To Tell If We're Beating COVID-19 от minutephysics, я набросал в свободное (от удаленной работы и домашних дел) время сервис, который на основе данных с Карты распространения коронавируса в России и мире от Яндекса строит графики, аналогичные тем, что на странице Covid Trends. Вот, что из этого вышло:

Интересно? Погнали!

Доброго времени суток, друзья!

Данная статья представляет собой небольшую подборку примеров работы с Canvas API, к которой удобно обращаться при необходимости вспомнить изученный материал.

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

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

Код разбит на отдельные блоки-песочницы, которые для удобства чтения помещены под «кат».

Парочка важных моментов.

Ширину и высоту холста лучше определять с помощью атрибутов:

<canvas width="300" height="300"></canvas>

Если мы хотим, чтобы холстом была вся область просмотра, то делаем следующее:

const width = canvas.width = innerWidth
const height = canvas.height = innerHeight

Холст и двумерный контекст рисования я обычно определяю следующим образом:

const canvas = document.querySelector('canvas')
// не путать с объектом jQuery
const $ = canvas.getContext('2d')

Довольно слов.

Доброго времени суток, друзья!

Представляю вашему вниманию перевод статьи «Understanding (all) JavaScript module formats and tools» автора Dixin.

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

• IIFE модуль: шаблон JS модуля
• Открытый модуль: шаблон открытого JS модуля
• CJS модуль: CommonJS модуль или Node.js модуль
• AMD модуль: асинхронное определение модуля или RequireJS модуль
• UMD модуль: универсальное определение модуля или UmdJS модуль
• ES модуль: ECMAScript2015 или ES6 модуль
• ES динамический модуль: ECMAScript2020 или ES11 динамический модуль
• Системный модуль: SystemJS модуль
• Webpack модуль: транспиляция и сборка CJS, AMD и ES модулей
• Babel модуль: транспиляция ES модуля
• TypeScript модуль: транспиляция CJS, AMD, ES и SystemJS модулей

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

Когда хотели бы махнуть в Питер на выходные, но судьба распорядилась иначе. Зато можно сходить на питерский онлайн-митап или погулять по 3D выставке, сделав себе аватар, как в Симах. А больше всего мероприятий на этой неделе будет для тех, кто только собирается войти в ИТ. Так что если вам такое уже не нужно — советуйте знакомым.

Всем привет, меня зовут Владимир. Я занимаюсь фронтенд разработкой в Tinkoff.ru.

В Ангуляре для передачи данных внутри приложения или для инкапсуляции бизнес-логики мы привыкли использовать сервисы. Для управления асинхронными потоками отлично подходит RxJS.

Ангуляр в сочетании с RxJS позволяет писать в декларативном стиле, коротко и ясно. Но иногда мы сталкиваемся со сторонними библиотеками или API, которые используют коллбэки, промисы, тем самым подталкивают нас отступить от привычного стиля и писать императивно.

Цель статьи — показать на примере подобных API, как с помощью RxJS их можно без проблем обернуть в Observable-сервисы. Это поможет достичь удобства использования в Ангуляре. Начнем с Geolocation API.

Я опишу два финта, с помощью которых можно обойти некоторые ограничения google translate.

1. Ограничение на количество символов у google translate online то ли 3900, то ли 5000 символов. Иногда нужно больше, а создавать html-файл с текстом неохота. Чтобы обойти это ограничение, создайте html-файл следующего содержания:

<!DOCTYPE HTML>
<html>
 <head>
   <title>Google translator without limits.</title>
 </head>

 <body>
Google translator without limits.  Here comes the English text. It is necessary that translator to work. 
If you do not translate from English, insert the text in your language. Not in the window, but in html.<br>
<textarea id="test" rows="10" cols="45" placeholder="Paste text into this window."></textarea>
<p id="result"></p>
<script>
var textarea = document.getElementById('test');
var result = document.getElementById('result');

function updateResult() {
    result.innerHTML = textarea.value.replace(/\n/g, '<br>');
}

textarea.oninput = updateResult;

</script>
 </body>
</html>

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

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

Большую часть жизни я просто махал на них рукой и проходил мимо. Эти глупцы не понимают очевидных вещей, и я не нанимался разъяснять каждому js-нику, почему его код — это не разработка, а игрушечное прототипирование. Но время идёт, а количество идиотов вокруг и не думает уменьшаться, вместо того, чтобы всей своей фронтенд индустрией переехать наконец на статический тайпскрипт, эти ослы начинают использовать всякие кложуры, писать тонны тестов, и идти на все мыслимые ухищрения — лишь бы не разбираться в типах.

Однажды, в одной продуктовой команде захотели разработать мобильное приложение, чтобы проверить гипотезу востребованности продукта и его удобства для пользователей. И то, что в команде не было мобильных разработчиков, не помешало. Два фронтенд-разработчика взяли React Native и за три месяца написали приложение. Тестирование гипотезы прошло успешно, приложение продолжает развивается и вызывает интерес других команд в компании.


Изображение из описания инструмента: www.semrush.com/news/position-tracking-on-the-go.

Это краткое описание истории команды Артёма Лашевского, который на три месяца из фронтенд-разработчика стал мобильным. Подробнее, как это произошло, читайте в расшифровке доклада Артёма на FrontendConf 2019: что такое React Native, почему именно он, пошаговая инструкция создания приложения и выбор нужных библиотек и компонентов.

Привет, Хабр!

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

• DOM — это стейт. Поскольку у нас нет фреймворка, сразу забываем про функциональщину, и возвращаемся к императивному ООП. Веб-компоненты — это долгоживущие узлы DOM, инкапсулирующие свой стейт и имеющие публичное API. Они не пересоздаются, а изменяются. Значит DOM мы должны рассматривать не только как представление, но как хранилище бизнес-объектов, а значит и строить иерерхию компонентов нужно с учетом удобства их взаимодействия.
• Взаимодействие компонентов. Компоненты могут взаимодействовать посредством прямых вызовов, обмена колбэками, или посредством восходящих / нисходящих пользовательских событий DOM. Последний способ наиболее предпочтителен, так как снижает взаимную зацепленность (coupling), и упорядочивает граф связей (см. пример ниже).

Доброго времени суток, друзья.

Представляю вашему вниманию перевод статьи «Storage for the Web» автора Pete LePage.

Существует несколько технологий для хранения данных в браузере. Какая из них лучше?

Интернет-соединение может быть плохим или вовсе отсутствовать в определенных местах. Поэтому поддержка оффлайн-режима является одной из ключевых особенностей прогрессивных веб-приложений. Даже при наличии высокоскоростного подключения разумно применять кэширование и другие техники для улучшения пользовательского опыта. Существует несколько способов сохранения файлов (HTML, JavaScript, CSS, изображения и т.д.) и данных (пользовательские данные, новостные статьи и др.). Но какое решение лучше выбрать? И как обеспечить его долговечность?

Вкратце

Я создал новый проект Интерактивные эксперименты с машинным обучением на GitHub. Каждый эксперимент состоит из Jupyter/Colab ноутбука, показывающего как модель тренировалась, и Демо странички, показывающей модель в действии прямо в вашем браузере.

Несмотря на то, что машинные модели в репозитории могут быть немного "туповатенькими" (помните, это всего-лишь эксперименты, а не вылизанный код, готовый к "заливке на продакшн" и дальнейшему управлению новыми Tesla), они будут стараться как могут чтобы:

• Распознать цифры и прочие эскизы, которые вы нарисуете в браузере
• Определить и распознать объекты на видео из вашей камеры
• Классифицировать изображения, загруженные вами
• Написать с вами поэму в стиле Шекспира
• И даже поиграть с вами в камень-ножницы-бумагу
• и пр.

Я тренировал модели на Python с использованием TensorFlow 2 с поддержкой Keras. Для демо-приложения я использовал React и JavaScript версию Tensorflow.

Здравствуйте, господа, в этой статье я поделюсь опытом создания приложения учёта трат, в частности отвечу на следующие вопросы:

1. Зачем мне приложение учёта трат?
2. Почему это личный проект?
3. Почему проект на Git+JS?

1. Зачем мне приложение учёта трат?

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