Filter by tag: Science
  • Using redux-form validation with redux-saga by Ast

    If you work with redux apps a lot, you definitely heard about the `redux-form` package, because working with forms without it is a pain. If not, you should know it simplifies form creation a lot. Even the complex multi-step forms with nested fields could be implemented almost effortlessly using it. The API of the package was recently revamped and it's super fun to use now, but it's also pretty big and you definitely can use some hints on it! :) 

    Read more
  • How to avoid concurrency issues in React by Ast

    React proposes a simple declarative way to build an application's view. It's straightforward to write a hierarchy of stateless components or to change a state synchronously. The whole app works as an integration of two pure functions "state(event)" and "view(state)". The behavior is testable and predictable. But you can't make something complex without depending on an external data sources integration: side effects come into the stage. Beware, you're approaching the Dark Zone of functional programming now :) 

    Read more
  • A Few Notes on Composition of Reducers by Ast

    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:

    Read more
  • Writing Modern SPA in JavaScript: Package Management by Ast

    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:

    • What language should I use?
      JavaScript (es3, es5, es6)? TypeScript? CoffeeScript? Whatever-Else-Script?
    • How I should manage my dependencies?
      Can I just copy them to the project? Or should I use git submodules? Maybe I could make a use of some package manager (npm, bower)?
    • How should I assemble my code for frontend?
      Isn't the old good «just concatenate them all» the best one? Or should I use browserify? A little bit of webpack?
    • How should I use styles?
      Can I just add a style tag with an external css to my HTML file? Or should I use something more complex like BEM? Or can I just inline it?
    • What framework should I use for my application base?
      Should it be vanilla JavaScript? Or jQuery? Backbone? Angular? Maybe Angular 2 (two is bigger than one — therefore it should be better, right?), React?
    • How should I manage the data in my application?
      A lot of buzzwords here. Flow? Redux? Relay? MobX? Can't I just do it the old good way (like my father and his father did)?
    • Can't I just shoot myself in the head instead of diving into this mess?

    You can't write modern JavaScript and ignore those questions. So I'll try to solve this buzzword-hell-puzzle by starting a new project from scratch. We will be writing a new application with a small steps and every single step will be introducing one thing at a time.

    You should understand: sometimes you can definitely say that the tool named A is better than the tool named B. But sometimes you should also choose from tools with comparable awesomeness — just take the most beautiful one (as you see it now).

    Read more
  • Начните использовать ES6 и SASS в браузерах сегодня by Ast

    javascript

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

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

    Read more
  • Валидация форм на React JS by Ast

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

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

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

    Но не в этом случае. Если назначить props уже после создания элемента (чего делать не стоит — это, к слову, warning), они не сохранятся после пересоздания компонента, когда React решит еще раз запустить render(). Так что жесткая связь лишает главного преимущества React — реактивных view. Правильным решением было бы использовать события — они позволяют общаться элементам, не связывая их напрямую друг с другом. Всё, что для этого нужно — общая шина. Предлагаю своё решение, вы можете сразу посмотреть демо.

    Read more
  • Модальное окно на React JS by Ast

    bycycle

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

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

    Read more
  • Событийная архитектура веб-приложения by Ast

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

    Приведу пример простейшего API корзины интернет-магазина, а для событий используем уже имеющуюся «шину» — элемент body.

    function add(item_id, quantity) {
        $.ajax({
            type: "POST",
            url: "/api/cart/add",
            dataType: 'json',
            data: {item_id: item_id, quantity: quantity}
        }).done(function (data) {
            $('body').trigger('QuantityChanged', [data.item_id, data.quantity]);
            $('body').trigger('PriceChanged', [data.item_id, data.sum]);
        });
    };
    

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

    /**
     * Обновить количество товара в корзине
     */
    $('body').on('QuantityChanged', function (e, item_id, quantity) {
        $('[data-item-quantity="' + item_id + '"]').html(quantity);
    });
    
    /**
     * Обновить цену товара в корзине
     */
    $('body').on('PriceChanged', function (e, item_id, sum) {
        $('[data-item-sum="' + item_id + '"]').html(sum);
    });
    

    Никто теперь не мешает нам расширить систему, добавив на какой-то отдельной странице дополнительное действие при добавлении товара в корзину. И это всё без изменения API, без изменения старых событий и без условных операторов.

  • Изменение src у изображения в Opera by Ast

    Казалось бы, ну что может быть проще чем сменить изображение на странице при помощи 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 подобрела и стала менять послушно менять изображение.