Filter by tag: Javascript

Managing the state of an application with libraries like `redux` is awesome. It provides a really easy way to write simple and testable code for state transitions. You only need to decide on a structure of the desired state and write a corresponding pure function.

There is no doubt that a reducer could look super simple in the cases like the following one:



Our main task as developers is to keep all reducers as simple as possible. Simple reducer is easily understandable and it's not a big deal to write a couple of helpful tests for it. But the state grows bigger and becomes more and more complex as we add more cool features to our apps. We need a technique to hide this complexity somewhere.

Every reducer is just a common pure function. No magic at all. Therefore it's possible to write such a reducer function which will take a set of other reducers on its input to produce their results in a combination of some sort. Let's look at a few examples:

Combine a set of reducers into a map of properties

Let's assume that our app needs two different counters at the same time. It would be great to code something like that (with magic `combineReducers` function):



And it's exactly what is possible with the standard `combineReducers` function from `redux` library. But be aware that as we use the same `counter` reducer for counter1 and counter2, they react the same way and counter's values will be the same too.

Combine a set of reducers into an indexed storage

Let's imagine that we want a couple of such state structures. We must add an `id` parameter into the action to be able to determine which one of the states we want to change.



Let the power of pure functions be with you.


Why yet another one tutorial?

A single-page application (SPA) is a web application or web site that fits on a single web page with the goal of providing a more fluid user experience similar to a desktop application.

I've been thinking of a complete tutorial on writing SPA in modern JavaScript for a long time. «There are a lot of such lessons» — you can say and be 100% right. But most of them have a very confusing part for newcomers: the horrific amount of buzzwords! The days when you were able to write the simplest «Hello World» program in just a few lines of code are long gone. Now you should know good enough answers to many important questions before you could even start coding.


code

Браузеры всегда были очень инертной средой для исполнения наших программ. Даже когда язык JavaScript ещё не развивался так быстро как сейчас, браузеры уже не успевали за ним. Годами на троне сидел какой-нибудь хтонический монстр вроде IE6 и заставлял с ним считаться каждого. Нам пришлось на долгое время забыть об использовании чистых языковых конструкций и научиться доверять очередной библиотеке, знающей разницу между браузерами и их версиями. Появились армии разработчиков, неплохо знающих jQuery, но как огня боящихся самого языка JavaScript. В то же время, дела со стилями в чем-то были еще хуже. Несмотря на появление множества новых свойств, сам формат не получил вообще никаких значимых улучшений и, в сыром виде, даже сейчас едва ли может быть удобен кому-либо.

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


Нам нужны формы. Больше форм.

Любой разработчик знает это. Каким бы хитрым фреймоворком вы ни пользовались, какие бы неожиданные идеи ни привносила в процесс разработки ваша очередная революционная концепция, как бы ни был устроен поток данных приложения, вам никуда не уйти от форм. Как только ваше приложение требует ввода более-менее сложных данных, старое доброе решение остается самым простым и эффективным, самым понятным пользователю и простым в реализации. И в React Js та же самая, старая как мир история — нам снова нужны формы.


Велосипед

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

И хотя в арсенале любого фронтенд-разработчика есть простая как топор функция confirm(), будем честны: она страшна как смертный грех, по-разному выглядит в разных браузерах и запросто может разрушить весь эффект от вашего крутого дизайна. Выход один — использовать собственное модальное окно. Всё крайне просто, если вы используете какой-нибудь jQuery и императивно командуете DOM-элементом, в котором оно описано, тем более что и готовых решений существует множество. А вот если вы используете React JS с его парадигмой реактивного программирования, решение может быть достаточно хитрым из-за особенностей связи между родительскими и дочерними компонентами.


2+2

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


Казалось бы, ну что может быть проще чем сменить изображение на странице при помощи JavaScript? Вроде на дворе самый настоящий 2010 год, уже давно в ходу разные кроссбраузерные библиотеки вроде jQuery, предусматривающие малейший каприз любого движка. Ну какие проблемы вообще могут возникнуть? Оказалось, всякие. Очевидная попытка просто сменить src у img не дала ровным счетом ничего.


  $('#kcaptcha').attr('src', '../includes/captcha/run.php');

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


$('#kcaptcha').attr('src', '../includes/captcha/run.php#' Math.random());

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


  $('#kcaptcha').attr('src', '../includes/captcha/run.php?junk=' Math.random());

Вот тут Opera подобрела и стала менять послушно менять изображение.