Привет! На этой неделе с вами @andreypopp. Занимаюсь разработкой на JS/Python. С недавнего времени живу в Санкт-Петербурге.

Давайте поговорим о ФП в разработке интерфейсов. От концептов и языков программирования до библиотек и фрэймворков.

FRP: все о нём говорят, но мне до сих пор непонятна его ценность, хотя очень интересно. Кто-нибудь расскажет?

PureScript интересен тем, что позволяет судить об “эффектах” в приложении. Например: “пусть эта функция не пишет в DOM”, “тут нет I/O"

React: "опиши UI один раз как функцию от данных, не надо описывать миллион способов изменить UI при изменении данных”

Пришел в JS только после появления React.js. Кроме JS и Python применял на практике Erlang и Scala. Пробовал ещё много функциональщины...

Из интересного для меня на эту тему: Immediate mode UI (React, …), стат. типизация (PureScript, OCaml, …), FRP.

.@jsunderhood ого, в purescript даже typeclasses запилены, крутяк.

@jsunderhood elm-lang.org/blog/blazing-f…

. @aluuu когда я смотрел Elm этого еще не было. Но и теперь непонятно что мне даст FRP. По-моему сложно постоянно брать “время” в расчет.

@jsunderhood ФП в UI ничем не отличается от ФП на бекенде, в консоли или еще где-то.

. @listochkin согласен, но есть же какие-то специфичные штуки: immediate mode ui тот же

Awesome Elm: bit.ly/1M5EeV2 список ресурсов, статей и примеров для Elm. @jsunderhood pic.twitter.com/HawBQ07MH2

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

Поэтому "FRP как архитектура всего приложения" не очень хорошая идея на мой взгляд. Для анимаций, наверное, самое-то.

Хорошие абстракции должны изолировать время и асинхронность.

В React/Flux архитектуре время изолируется в хранилищах вместо того, чтобы утекать в UI. UI — отображение определенного момента времени.

Redux от @dan_abramov реализует управление состоянием лучше чем Flux: вместо изменяющегося состояния есть "рецепт как изменить состояние"

Что, кстати, уже снова близко к FRP, но есть чувство что там это оправдано: где-то время нужно учиывать. Главное делать это контролируемо.

Возможно последний твит это все-же результат моего непонимания FRP (или понимания? :-)

Следующий шаг в управлении изменяющемся состоянии это CRDT структуры данных где порядок операций значения не имеет. Прячет время ещё дальше

@jsunderhood да, смотрел недавно, круто, но пока не одуплил, нужно покурить paper . За счет чего там игнорится время?

. @__fro операции над данными можно менять местами и в какой-то момент у всех (сервер, клиент, другой клиент, ...) будет одна картина мира

. @__fro вот кстати классный понятный paper на тему CRDT: gsd.di.uminho.pt/members/cbm/ps… (осторожно PDF)

@jsunderhood и что будет, если, скажем, у нас googledocs и оба юзера одновременно вставили разные символы в одно и тоже место?

. @__fro оба юзера увидят оба символа в одном и том же порядке, непонятно в каком, главное что порядок будет одним для всех

Кто ещё не видел есть реализация CRDT на JS (работает конечно же и в браузерах): swarmjs.github.io от @gritzko

@__fro @jsunderhood оно не игнорится, оно явно учитывается; все операции помечены timestamp; каждое состояние - это версия.

@gritzko @jsunderhood это часть CRDT или надстройка?

@__fro @jsunderhood это CRDT в @swarm_js, op-based с lamport timestamps; CRDT в целом это очень широкое определение

@__fro @jsunderhood кстати, статья в WP очень хорошего качества en.wikipedia.org/wiki/Conflict-…, вариант Swarm: swarmjs.github.io/articles/lampo…

@jsunderhood and declare dependencies between phenomena, and that's it. A Cycle.js app is fully declarative.

.@jsunderhood Давайте обудим тестирование. Кто, что и как теститует. У кого какое покрытие.

У нас тонкая “запускалка” поверх webpack для Jasmine спек: github.com/prometheusrese…

@jsunderhood mocha + react в нодовом окружении для юнитов. Еще где то в моем идеальном мире должен быть селениум, но пока увы

@Semenov @jsunderhood тестировать должны пользователи и сообщать об ошибках разработчику.

@jsunderhood А на чем нынче модно/удобно делать REST API на Node?

Создатель @babeljs присоединяется к команде FB — хорошо когда за таким полезным проектом целая компания.

Вчера ночью чуть-чуть обсуждали REST API. Интересно, появление GraphQL/Relay и Falcor вытеснит классический REST или нет?

У нас есть своя похожая штука: HTSQL htsql.org/doc/overview.h…, более близка к полноценному языку запросов, но у нас и требования другие

@jsunderhood Для внутренних API - вытеснит 100%.

. @freiksenet почему только для внутренних? Когда участвовал в хакатонах всегда хотелось чего-то подобного GraphQL

. @freiksenet если бы еще в одном запросе и разные источники можно было запрашивать — вообще класс. Идея для стартапа — GraphQL Mashups ;-)

@jsunderhood А, ну сделай схему и resolve. GraphQL только систему типов дает, он нейтрален в плане источника(ов).

. @freiksenet ага, об этом и речь, был бы SaaS, где я эту схему составлю и который мне обеспечит кэширования для датасетов и т.д.

. @freiksenet расскажи про reindex.io в паре твитов? BaaS? Какие фичи? Прайс? Как-то связаны с FB?

@jsunderhood Если коротко - мы как Firebase или Parse но с GraphQL API. BaaS. Прайс еще не уверены, но думаю как у конкурентов.

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

@jsunderhood Сейчас переходим на graphql-js, у нас там другой подход в плане выполнения запросов и мы обсуждаем как сделать совместимость.

@jsunderhood По-моему REST легче контроллировать в плане потребления ресурсов. GraphQL можно сразу все запросить, сложнее делать rate limit.

. @freiksenet можно брать деньги за переходы в графе

@jsunderhood я бы ставил на Datomic

. @chicoxyzzy Datomic хорош, но это БД. GraphQL/Falcor не заботятся о хранении данных, думаю их легче начать использовать

@jsunderhood так ведь docs.datomic.com/query.html считай тот же GraphQL. Уже есть тонна реализаций для JS

. @chicoxyzzy ок, это про Datalog, а что за реализации для JS? Я видел DataScript для CLJS

@jsunderhood @ALF_er стоит немного подождать, Datomic и его инфраструктура достаточно молоды, но IMHO это гораздо перспективнее GraphQL IRL

@chicoxyzzy @jsunderhood @ALF_er not sure who from #graphql/Datomic/Falcor group will win, but definitely not REST. It will not die though.

@chicoxyzzy @jsunderhood @ALF_er using REST for apps dev always felt awkward, http was never designed for apps and has are tons of issues.

@chicoxyzzy @jsunderhood @ALF_er I don't want to solve countless sync problems, I just want to work with data and code biz logic #Firebase

Кто-нибудь должен сделать фрэймворк для shell скриптов, чтобы подтягивать функции с npm. Я с удовольствием буду его использовать.

@jsunderhood Ты просто старый

"Makefile это JSX командной строки” — пока не попробуешь не поймешь в чем польза

Вот пример тонкого Makefile для JS проекта: github.com/andreypopp/aut… на мой взгляд приятнее чем npm скрипты + директория scripts/

Поэкспериментировал с темингом для React компонент github.com/andreypopp/ret… Идея: протокол для компонент, которым можно изменять внешний вид

Можно использовать с inline styles, css modules, … Как вам API? Чего не хватает?

@jsunderhood вероятно разработчик столкнется с тем что для другой темы нужна другая разметка. Такое было два раза из двух, в моей практике.

. @olebedev можно передавать функции/компоненты как часть темы для компонента — так можно заменять часть разметки

@jsunderhood Но при этом в самом компоненте должно быть предусмотрено заранее, что вот такую-то часть можно заменять? @olebedev

. @toivonens да, это контролируется компонентом, никакой магии

@jsunderhood В случае теминга, может будет проще трансформировать дерево компонентов при запуске или изменении темы?

. @__fro дерево не реализуется в один момент, оно ленивое (через вызовы render()), поэтому нужен способ изнутри чтобы инжектит тему

Альтернатива: делать теминг на уровне системы модулей, так можно инжектить нужные стили статически (нужен webpack-loader какой-нибудь)

@jsunderhood Компонент должен знать обо всех своих темах заранее :-) В БЭМ можно что угодно доопределить, но больше нигде так нельзя :-(

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

Кто еще не знаком с CSS modules github.com/css-modules/cs… компонентный подход к стилям

@jsunderhood хочу заметить, что первый компонентный подход — БЭМ. CSS Modules интересны тем, что он автоматический.

. @andrey_sitnik я хотел сказать первый компонентный подход который работает :-)

@jsunderhood вообще,как вариант, можно сделать фабрику фабрик компонентов, которая бы возвращала themed фабрики.Их и использовать в рантайме

Подсказали классную утилиту для демок React компонент github.com/insin/react-he… — heatpack ./WidgetDemo.js

Идея: плагин для webpack который позволяет редактировать props компонент прямо в браузере. Сохраняет обратно в исходники.

Наводишь мышкой на экране на элемент и открываешь диалог с редакторов свойств. Прямо в приложении.

Для этого нужно будет аннотировать все вызовы React.createElement позицией каждого prop в исходниках

@jsunderhood так плагин для Chrome DevTools такое позволяет делать

. @__fro Значит можно попробовать добавить ему возможность сохранять изменения

@jsunderhood как браузер будет работать с fs?

. @iamstarkov через webpack-dev-server, нужен плагин именно к нему

@jsunderhood эмм.. А куда? ) Куда сохранять? Ты имеешь ввиду defaults?

. @__fro прямо в том место где создаётся React элемент. Это можно будет делать только свойств переданных как литералы a=“…”, a={1}, a={{…}}

@iamstarkov @jsunderhood @ChromeDevTools таки умеет маппить сорцы на fs )

@iamstarkov @jsunderhood @ChromeDevTools не знаю, но я могу запилить. Я могу править из CDT, идет сохранение в FS и происходит hot reload.

Есть мнение что devtools должны быть не в отдельной панели UI, а частью самого приложения. //cc @dan_abramov как эксперта по DX

DX — developer experience, аналог UX.

@listochkin @alexeyraspopov @jsunderhood Мы их «вытащим» в remote потом. Первый этап — сделать их мощными, а не мучаться с Chrome API

@listochkin @alexeyraspopov @jsunderhood Цель в том числе чтобы они не были привязаны к Хрому. Например чтобы можно было их в отдельное окно

@dan_abramov @alexeyraspopov @jsunderhood и я о том же. Для девелопера важно, что инструмент умеет, а не как работает или где расположен.

. @listochkin @dan_abramov согласен, просто chrome devtools это “прошлое" когда интроспекцию можно было делать только на DOM/BOM уровне

Сейчас когда интроспекцию можно делать на уровне приложения (React, Redux) можно экспериментировать с новыми видами, интерфейсами devtools

@jsunderhood с моей точки зрения CDT - это удобная панелька с табиками, куда можно добавить ништяков. Каких? - дело фантазии @dan_abramov

Дискуссия про Babel и нестандартные расширения языка (JSX): reddit.com/r/javascript/c…

@jsunderhood Из DOMа.

Кстати, @jsunderhood, тут была идейка у меня и @Rukomoynikov, покататься где-нибудь на выходных по Москве. Кто с нами?

. @marinintim в es6 выбор фактически между const и let, var сломан

@jsunderhood как я понимаю, популярность const идёт из функциональных кругов

@jsunderhood @marinintim а можно подробнее, почему var сломан?

. @Sigiller @marinintim let биндинги более локальны (внутри блока а не внутри функции как var). Меньше шанса на ошибки.

@Sigiller @jsunderhood @marinintim Нет задач под var. Есть let (который к тому-же избавляет от лишних замыканий) и const для констант ☺️

@jsunderhood врывающийся в студию вопрос (прощу прощения)
Ребята, есть идеи как описывать JS Doc на props в React классах/компонентах? =)

@ymatuhin @jsunderhood @Sigiller @marinintim Я бы вообще сделал что var = let, а let = const.

. @freiksenet насчёт let = const наверное соглашусь, нужен плагин для Babel.js

@_nezed @jsunderhood Оригинальный вариант — использовать propTypes

const - normal
let - code smell
var - legacy

/cc @_ericelliott

Действительно, let, const или var? В es6 я использую let, так меньше набирать да и читается отлично. twitter.com/_ericelliott/s…

14:09

@jsunderhood Расскажи, пожалуйста, про своё рабочее окружение, IDE, какие-нибудь полезные инстументы, которыми ты часто пользуешься.

. @mista_k vim