image


В четверг 8 февраля в 19:00 в коворкинге «Соль» пройдет первая в 2018 году встреча UralJS. Разберемся, почему в Контуре TypeScript победил Flow, послушаем рецепты оптимизации от Лёши Иванова — злого марсианина и члена программного комитета Fronttalks, и поспорим, что круче: функциональщина или ООП.


UralJS появился как эксперимент — группе коллег не хватало профессиональной движухи, и мы решили ее организовать. В первый раз собралось 70 разработчиков, а теперь мы закрываем регистрацию на сотне участников, потому что площадки не резиновые. Расширяется география — к нам в Екатеринбург приезжали гости из Тюмени, Челябинска и Перми.


За 2017 год мы провели 5 митапов. Обсуждали, что делать, если маленький пет-проект привлечет миллион пользователей, рассказывали, какой классный Vue и тут же бомбили по этому поводу, разбирались с интернационализацией и восхищались потокам в JS. Летом мы попробовали другие форматы. Андрей Старовойт из JetBrains сделал большой доклад о том, как разработчики WebStorm выбирают технологии для поддержки. Вместе кодили на выходных — щупали Ангуляр и решали одну и ту же задачу пять раз с разными партнерами и ограничениями.


Что будет на этот раз:


Николай Карев, фрилансер — this is зло


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


Михаил Шатихин, Контур — Безжалостная типизация


Поговорим о типизации приложений на TypeScript. Покажу, как добавить с нуля типы в Redux-приложение и получить максимум контроля над приложением. Покажу, почему в типизированном приложении можно писать меньше тестов и из него полностью исчезают ошибки определённых классов — если компилируется, то просто работает. Раскрою негативную сторону: расскажу, насколько увеличивается время разработки и размер кодовой базы. Объясню, как типы помогают привлечь бэкендеров к разработке фронтенда.


Алексей Иванов, Злые марсиане — React и данные: Эффективные способы хранения и изменения стейта


При компиляции JSX в JS получаются функции. Одни функции вложены в другие, другие вложены в третьи. Если вызвать самую верхнюю функцию, то сначала получится VirtualDOM, а потом и просто DOM.


Пока все хорошо. Но теперь нам нужно поменять какие-то данные в приложении, и изменить наш DOM на их основе. И вот тут начинаются разные нюансы. Все ли изменения одинаково полезны? Какие правки будут вызвать перерендер, а какие нет? Как React выбирает, что именно изменить? Какие изменения в VirtualDOM позовут за собой изменения DOM, а какие нет? Как организовать свои данные так, чтобы приложение работало максимально быстро?


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




Участие бесплатное, но надо зарегистрироваться, чтобы организаторы подготовили чай, кофе и снеки для всех гостей.


Регистрация — тут.


Записи докладов появятся на YouTube-канале после митапа.

Комментарии (3)


  1. vasIvas
    26.01.2018 10:57

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

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


    1. tenebricosa Автор
      26.01.2018 11:45

      Призываю нашего докладчика karevn в дискуссию :)


    1. vasIvas
      26.01.2018 16:21

      Ещё стоит добавить что бояться this не стоит, пока обращения происходят к свойствам объекта получаемого по ссылке this (this.object.prop). Обращение с одной точкой, в большинстве случаев, свидетельствуют о плохо продуманной архитектуре. Но из этого не следует что все части приложения нуждаются в столь продуманной архитектуре, которая будет лишь усложнять процесс разработки не давая никаких плюсов.

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