всем привет, эту неделю с вами будет @deepsweet. меня зовут Кир, кто-то может помнить меня по Яндексу, для остальных я просто JS-разработчик

т.к. у меня GMT+7 и вы скорей всего спите, я пока поспамлю темами, на которые мне было бы интересно поговорить :)

webpack, Babel, React, Flux, BEM (в хорошем смысле), изоморфность, фотки тупых людей, иммутабельность, парное программирование, Вьетнам.

@jsunderhood GMT +7 это какой город?)

.@ivan_krivonos Хошимин

на текущей работе есть всё из этого списка, очень красиво переплетённое. да-да, React + BEM :) с наследованием по уровням переопределения.

@jsunderhood уже смотрели в сторону CSS Modules? Может ли этот концепт заменить BEM? Насколько вообще оно практично?

.@alexeyraspopov да, смотрели ещё с первых коммитов в css-loader – сама идея уникального локального скоупа для стилей компонента заманчивая.

.@alexeyraspopov но лично мне совсем не нравится подход к внедрению этого в React – github.com/css-modules/cs… – когда компонент думает о теме.

для всех – тема CSS Modules началась примерно отсюда github.com/webpack/css-lo…, и развивается дальше здесь github.com/css-modules

идея в чём-то гениальна: css-loader для webpack превращает классы из стилей в хэши, которые потом экспортируются как из обычного js-модуля.

дальше где-то, где эти стили нужны (в том же react-компоненте), они импортируются, и появляется доступ к маппингу "класс -> хэш".

но для уникальных хэшей всё равно нужны уникальные классы, и для этого внутри стилей вполне можно использовать то же BEM-именование.

в итоге получается такая себе автоматизированная связка BEM + <style scoped> без лишней боли по поводу конфликтов и пересечений.

@jsunderhood разве уникальные? Можно использовать одни и те же имена в разных файлах и они будут разруливаться без конфликтов

.@alexeyraspopov я имею в виду, что внутри файлов стилей всё равно нужно как-то именовать классы, и идея BEM (например) здесь очень подходит

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

@jsunderhood нет, разные. В это вся фишка — никакого конфликта имен между файлами

.@alexeyraspopov а если у меня стили для одного компонента находятся в разных файлах? судя по докам берётся хэш от внутренностей :local()…

@jsunderhood У вас есть где-то снаружи project-stub или мини-проект, где можно увидеть как именно это красиво переплетено?

.@toivonens "стаба" нет, мы слишком ленивые и занятые. есть только все нужные технологии github.com/yummies/yummies + github.com/yummies/babel-…

кстати, как вам затея с эмоджи в коммитах? github.com/yummies/genera… 😼

@jsunderhood @toivonens мне вот этот стартер кит понравился из последних github.com/cdebotton/reac… там есть css modules

собственно, основная идея React + BEM в том, что JSX – говно, а BEMJSON – добро github.com/yummies/yummie…

дальше – наследование github.com/yummies/core-c…, ещё дальше – "уровни переопределения" или, как мы их называем, "слои" github.com/yummies/babel-…

BEM-модификатор – это класс, который (автоматически) наследуется от класса react-компонента и до/переопределяет BEMJSON из его render()'а.

про это всё определённо нужна отдельная статья + отдельный стартер-кит, но я уже даже не решаюсь давать обещания, всё тянется уже с мая.

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

уже в черновиках статья. в целом – Flux может быть абсолютно любым. RT @RusAlexander: @jsunderhood на чью реализацию похож ваш #flux ?

завтра будет день Flux: иммутабельные деревья, единое состояние, курсоры, GraphQL-like декларативность, префетчинг на сервере, изоморфность.

@jsunderhood как вы относитесь к @WebComponents ? Правда ли что появление #react есть следствие провала компонентов ?

.@RusAlexander личное моё мнение – это мертворожденная технология, которую зря пытаются форсить. React появился из-за общей убогости DOM.

.@RusAlexander с другой стороны, возможно ещё просто не пришло время, и появление "shady DOM" вместо полноценного Shadow DOM тому пример.

@jsunderhood Как уровни переопределения работают в этой связке? В html.

.@operatino в конечном итоге импортируется фабрика уже собранного и склеенного по всем уровням реакт-компонента.

.@operatino можно до/переопределять что угодно, как в BEMHTML, хоть тэг, хоть внутренности.

довольно интересная концепция получилась с "темами" – тема просто является отдельным слоем, начиная с темы "reset" github.com/yummies/theme-…

@jsunderhood То есть это кастомная реализация сборки с мерджем компонентов? Без БЭМ шаблонизаторов? Какие тулзы замешаны?

.@operatino основа – webpack + Babel, кастомной сборки как таковой нет, всё нужное уже есть в webpack + немного магии через babel-плагин.

пример корневого `.yummies.yml` из внутреннего проекта gist.github.com/deepsweet/15c8…

видимо эта неделя наконец-то заставит нас с @mistadikay сделать starter-kit.

магия заключается в спец. #-импорте:

import Example from '#example';
import ExampleTypeTestSizeBig from '#example?_type=test&_size=big';

Babel-плагин матчится на символ `#` в импорте и начинает искать файлы по слоям из конфига. находит – включает в цепочку наследований.

в конечном итоге в Example попадает обычная фабрика реактового компонента, который отнаследован по очереди от класса каждого слоя.

↓ github.com/yummies/babel-…

пример модификатора github.com/yummies/core-c… – `super.render()`

@jsunderhood много времени уже прошло, не сожалеешь? :)

.@silentroach 1) не сожалею, по-моему я ушёл очень вовремя 2) уже жалею :) но опыт жизни в Азии всё равно очень интересный и бесценный.

@jsunderhood Почему жалеешь? Что не так с Вьетнамом?

.@verkholantsev это страна, в которой уровень экономического развития слишком резко и быстро обогнал уровень сознания. со всеми вытекающими.

@jsunderhood что думаешь про redux?

.@silentroach Redux – крутой, но меня не покидает ощущение, что это какой-то мимолётный промежуточный этап, как и webpack HMR в целом.

@jsunderhood @andrey_sitnik @silentroach а как быть тогда, какую flux либу использовать?

.@thought_sync @andrey_sitnik @silentroach сегодня – Redux :) мой ответ был немного не о том, что Redux не надо использовать.

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

главное сильно и навсегда не залипнуть на "каноническом" Flux, это лишь начало :) завтра будут стримы, а послезавтра одно лишь телевидение.

@yuritkachenko @jsunderhood смотря что называть мимолетным. Для кого-то - 5 лет. Для фронтенда год-два быть в топе - очень круто.

@jsunderhood почему Въетнам? Как там ощущения вне офиса (или где вы работаете)? Долго там уже?

.@beshur почему – без понятия, просто было интересно :) вне офиса круглый год душное и влажное лето лето. вот уже почти год как живём.

.@beshur почему – без понятия, просто было интересно :) вне офиса круглый год душное и влажное лето. вот уже почти год как живём.

быстро набросал кое-какой Starter Kit github.com/yummies/starte… 🔥

уже не представляю как можно жить без "Object Rest/Spread Properties" github.com/sebmarkbage/ec… – даже если не войдёт в ES7, буду юзать плагин

вообще, колонка Stage в ES7+ пока выглядит довольно печально github.com/tc39/ecma262

Create random JSON objects using json-spawn and Chance.js github.com/luisfarzati/js…

Awesome list of Redux examples and middlewares github.com/xgrommx/awesom…

совсем забыл, со мной можно говорить про Diablo 2.

@jsunderhood Еще вот мои наработки по коллекционировании ресурсов об реактивности xgrommx.github.io/rx-book/conten… также тут есть видео, лекции и тд.

доброе утро. вчера спрашивали какое Flux решение мы используем… начну немного издалека, а закончу постом в медиум со ссылкой на репозиторий.

хорошее интро в Immutable Data на примере Immutable.js всё от того же фейсбука youtube.com/watch?v=I7IdS-…

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

это дерево иммутабельное, т.е. каждое изменение влечёт за собой новую версию дерева, отличную от старой.

в типичном приложении в дереве будет не так много основных явных веток, типа products list, product info и т.п.

"курсор" – это своеобразная ссылка на ветку данных в дереве. простой пример на основе всё того же Immutable.js github.com/facebook/immut…

"cursor path" – это путь к этой ветке или к конечным данным. обычно представляется в виде массива, [ 'products', ID, 'details', 'price' ].

для дерева и курсоров мы используем Baobab github.com/Yomguithereal/… – ничего лишнего, всё довольно просто и прозрачно.

дерево эмитит событие `update`, на основе которого можно и нужно обновлять, например, курсоры, т.к. дерево уже новое, а ссылки старые.

событие `update` есть и у самих курсоров – изменились данные по конкретному пути в дереве.

сначала мы делали так: всё дерево помещается в локальный стэйт корневого компонента. по подписке на update стэйт обновляется новый деревом.

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

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

из минусов: жёсткая связанность компонентов через иерархию: компонент C зависел от курсора, который ему даст B, а тот в свою очередь от A.

"лишние" рендеры довольно легко отсекались через shouldComponentUpdate(), как и было завещано.

но потом моё внимание привлекла очень интересная особенность Baobab: есть событие `get` – были запрошены данные по такому-то пути. геттер.

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

Declarative data fetching in React components with Baobab medium.com/@mistadikay/de…

компоненты – максимально тупые. они просто рисуют данные как будто эти есть и всегда были. почти каждый компонент сам знает свой cursor path

в рутовом компоненте идёт подписка на геттер из дерева – если данных, которые запрошены отрисовкой компонента ещё нет, то дёргается экшн…

…который, как в самом обычном Flux, диспатчит событие, которое ловит стор, который складывает эти данные по нужному cursor path в дерево.

компонент по событию `update` от своего курсора самообновляется и перерисовывается. profit.

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

самый жир затеи – github.com/mistadikay/rea… – декларативный "запрос" данных. что-то вроде того же GraphQL, только поверх обычного Rest.

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

ещё одна интересная особенность – в дереве есть две осовных ветки – data и ui. в data собственно данные, а в ui – визуальные состояния…

типа выбранного пункта, нажатости чекбокса и т.д. это позволяет практически забесплатно сделать "историю" – отматывание всего состояния.

т.к. иммутабельное дерево создаёт новую версию на каждое изменение, ни что не мешает сохранять эти версии и сделать историю как в фотошопе.

@jsunderhood Правда про CLJS, но отлично про иммутабельность, историю из оной и вообще. youtube.com/watch?v=lDkrXT… youtube.com/watch?v=tUtLe1…

@jsunderhood А в вашем случае "дерево" — это BEMJSON или ещё над ним абстракция?

.@toivonens нет, не BEMJSON, произвольная структура данных, в ветки которой чаще всего складываются данные от сервера as is.

.@toivonens но твою идею я понял :)

@jsunderhood Просто ты упоминал до этого BEMJSON, и я пытаюсь понять, куда вы его там встроили.

.@toivonens это никак не связано с Yummies и BEM. пример в репозитории специально написан на JSX :) просто концепция, применимая везде.

кажется ведущий @jsunderhood отпросился от работы на неделю :) столько твиттов, хотя только вторник!

@jsunderhood не могу избавиться от ощущения что что-то с GraphQL и подобными решениями не так. Rest более лучше, конечно, но как-то тоже <_<

.@silentroach мы (пока) взяли только ту часть GraphQL, которая про декларативность в компоненте. а вот бэкендовый кусок – да, необычный.

два поста в тему: Your First GraphQL Server medium.com/@clayallsopp/y… / Moving from REST to GraphQL medium.com/@frikille/movi…

на данном этапе меня смущает даже сам синтаксис graphQL Query, но это просто с непривычки. с самой идеей по-моему всё в порядке.

@jsunderhood а как у вас дела с бэкендом? прослойка на ноде между клиентом и бэкендом на чем-то богомерзком? :)

.@silentroach обычный богомерзкий PHP, одни и те же REST-ручки которого "изоморфно" дёргаются нодой на сервере и аяксом на клиенте.

@jsunderhood Вопрос из зала: что лучше использовать Angular 2.0alpha (es6) или же React + ...) или есть еще хорошие альтернативы?

@jsunderhood интересно. как насчет отдельных констант типа pretty_name => path_in_tree, чтобы компонент не знал о структуре дерева

.@_cloudo можно чуть подробнее? не совсем уловил.

@jsunderhood на самом деле, если разобраться - баобаб тянет кучу всего лишнего. свой апи, курсоры, кучи методов (push, get). Нет даже has

@jsunderhood ну и основная идея - чистые функции, невозможна, set не возвращает новое дерево - он меняет текущее.даже если внутри это другое

.@milk_is_my_life а какие альтернативы? меня Baobab не смущает вообще ни чем. has есть в виде exist в @V2

@jsunderhood как относишься к сорхусу и его идее на каждую мелочь создавать по модулю?

.@silentroach :) забавный персонаж. в идее модульности нет ничего плохого, даже в таком, доведённом до абсурда виде. я даже что-то юзал.

.@silentroach но я примерно понимаю почему это может раздражать.

(речь о github.com/sindresorhus и его модулях типа github.com/sindresorhus/c…)

@jsunderhood идея - заменить путь к данным в дереве более семантичной константой

.@_cloudo вполне нормальная идея :) импортировать это из тех же constants, по аналогии с именами событий.

.@_cloudo но это не работает с динамическими путями типа github.com/mistadikay/rea…

@jsunderhood буквально вчера об это спросил @dan_abramov оказалось сделать это самому гораздо проще, чем кажется github.com/gaearon/redux/…

.@milk_is_my_life в моём мире set и не должен напрямую возвращать новое дерево, всё летает по кругу почти как в каноническом Flux.

@jsunderhood ещё вопрос. Для бем дерева вы данные подготавливаете прямо в шаблоне или где-то раньше? (что-то типа своего bemtree)

.@MaximSukharev а нет как такового бем-дерева, как и шаблона :) сырые данные идут напрямую в ветку дерева, оттуда компонент рисует как хочет

.@MaximSukharev в смысле нет одного большого BEMTREE -> BEMJSON, всё немного иначе.

а какое Flux решение используете вы и какие у него основные минусы и сложности?

@jsunderhood alt.js.org всё чётко

@jsunderhood Пробовал Альт; теперь хочу попробовать Редакс.

@sapegin @jsunderhood @jsunderhood тоже используюем alt.js. попробовать redux интересно.

@jsunderhood делал в свое время анализ флаксов для заказщика, в результате и перешел на redux docs.google.com/spreadsheets/d…

@jsunderhood Если у кого есть комментарии, критика к документу - это крайне желательно. Буду править)

@jsunderhood использовал reflux, alt, flummox и теперь пробую redux

@jsunderhood reflux — дурацкие экшены, нет единого диспатчера, alt — странный api, flummox — все ок, но есть redux :-), redux пока радует

@pomidore @jsunderhood только flux, только классика, только хардкор.

@jsunderhood понравилось использовать baobab вместо сторов.

brace yourself, завтра изоморфность.

о да. жду адептов секты правильных слов :) RT @lapanoid: @jsunderhood универсальность ;)

@jsunderhood vanilla js + свои сторы github.com/alexeyraspopov…

@jsunderhood У вас есть i18n? Кто как решает эту задачу с React?

@roman01la @jsunderhood использовал github.com/yahoo/react-in… все ок.

@dimchez @jsunderhood @roman01la метод translate прокидывался в компоненты как props.

@roman01la @jsunderhood использую github.com/piranha/puttext:
парсинг вызовов -> *.po -> *.json -> puttext(require('*.json'))

@roman01la @jsunderhood Polyglot.js от airbnb + своя привязка к Redux

@olebedev @jsunderhood @roman01la +1 к puttext, просто и сердито

Фронтаны, а может кто поможет найти решение или лучшие практики для smooth parallax scrolling? кто как делает @jsunderhood

коллеги на работе подходят с вопросами потому что нагуглили мои модули. удобно.

Все что обсуждал с @ir4y_ix и планировал запилить на прошлых выходных, сегодня рассказывает @deepsweet в @jsunderhood. Супер!

ооок, в CSS есть outline-offset codepen.io/SitePoint/pen/…

@jsunderhood А ещё он может быть отрицательным! В опере удобно было вёрстку так отлаживать, пока нормальный дебаггер не появился

минутка ванильной вёрстки закончилась.

какое название вашей должности/профессии наиболее полно отражает реальность и в целом вас устраивает?

моё "Senior Front-End Developer" уже явно вносит больше путаницы в головы менеджеров, чем что-либо проясняет.

@jsunderhood яжпрограммист

@jsunderhood просто js web dev, без аутсорсной энтерпрайзной софтверной инженерии 😤

@mr_mig_by @jsunderhood меня устраивает классическое software engineer.

@jsunderhood JavaScript Engineer

@jsunderhood разработчик интерфейсов

@jsunderhood Frontend Developer или разработчик интерфейсов. не люблю деление на Junior/Senior — оно искусственное.

A modular, progressive, and beautiful Markdown and HTML editor github.com/bevacqua/woofm…

могу расписать по шагам идею изоморфности на примере того же реакта, начиная со сборки. интересно/актуально?

готовых starter kit'ов и прочих стабов хватает, например github.com/RickWong/react… / github.com/webpack/react-… / github.com/DavidWells/iso…

суть одна: один и тот же "изоморфный" код должен строить начальный HTML на сервере и продолжать работать дальше на клиенте.

в React для этого предусмотрены обычный DOM `render()` и "серверные" `renderToString()` / `renderToStaticMarkup()` facebook.github.io/react/docs/top…

к слову, в react@0.14 их даже разнесут по разным модулям facebook.github.io/react/blog/201…

обычно webpack'ом делают одновременно два билда с двумя наборами бандлов на выходе: серверный и клиентский.

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

на сервере это обычный `request.url` из Express / Koa (koajs.com, наш выбор) / whatever, на клиенте – HTML5 History API.

стандартом де-факто является react-router github.com/rackt/react-ro…

на сервере:

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

через renderToStaticMarkup() (чтобы не было лишних атрибутов data-reactid, "чистый" HTML) строится руками доктайп, <head> и <body>.

через renderToString() вытягивается строка HTML из компонента, который решил рендерить роутер, и dangerouslySetInnerHTML вставляется в body.

вся эта портянка отправляется обратно в Express в виде ответа на запрошенный URL. казалось бы всё, наш HTML jт сервера готов.

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

а render() у реакта синхронный, и сам по себе ждать каких-то там экшенов и сторов не может и не будет.

для решения этой задачи мы выбрали способ, в котором данные запрашиваются после осознания нужного роута, но до фактического рендера.

придумали маппинг соответствия роута и экшна(ов) – серверный роутер дёргает нужный экшн и ждёт ответа от стора, пока тот не заполнится.

пришёл ответ – рендерим. передав данные через пропсы, или просто тупо, если всё построено на дереве, из которого компонент возьмёт всё сам.

Ajax with less suck - (and node.js HTTP client to match)
visionmedia.github.com/superagent/ – чуть не забыл, "изоморфный ajax".

@jsunderhood И все это быстро?

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

@jsunderhood почему Koa?

.@vladimore because we can :) генераторы, вот это всё. судя по стресс-тестам распределение нагрузки более равномерное.

очень важно для осознания: componentDidMount() не происходит "на сервере", т.к. ничего никуда не маунтится.

поэтому подписки на обновление сторов или дёргание каких-нибудь экшнов в этом методе будут проигнорированы renderToString()'ом.

и ровно из-за этого же использовать условия с `typeof window` или, прости господи, process.env.BROWSER и пр. – плохо.

весь чистый client-side компонента должен быть описан исключительно в его componentDidMount().

итак. на сервере теперь для нужного роута дёргаются нужные данные и вытягивается HTML-строка из нужных компонентов.

когда на клиенте активируется наш собранный клиентский бандл, он (как я представляю) построит VDOM и начнёт матчить с HTML по `data-reactid`

т.к. никаких данных, которые были запрошены на сервере, у клиента нет, то React просто построит diff относительно пустых данных и всё сотрёт

отсюда интересная проблема: даже если на клиенте заново дёрнуть такие же экшны по роуту, как и на сервере, не факт, что они будут идентичны.

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

мы не придумали ничего лучше (а затем нашли подтверждение правильности своей идеи в других Flux рещениях), чем передать данные в HTML.

ведь если подумать, то между сервером и клиентом нет абсолютно никакой связи, кроме как HTML, и только так можно связать "сессию".

@jsunderhood а почему нельзя:
React.render(<Handler />, document);
?

.@olebedev можно и нужно, вот только сторы пустые.

т.е. при серверном рендеринге, куда-нибудь в <body>:

<script id="_bootstrap" type="application/json">{ ololo: true }</script>

для клиентского бандла точкой входа является клиентский конструктор роутера, который, если есть "bootstrap", возьмёт оттуда данные.

сложит их в стор и сделает самый обычный React.render(…). в этой точке всё дальнейшнее управление роутами уходит в клиентский react-router.

теперь строка HTML от сервера полностью идентична тому, что построит реакт на клиенте. нулевой diff, profit.

дальнейший переход на другую страницу будет перехвачен роутером и выполнен только на клиенте. только в этом случае будет дёрнут экшн…

т.к. данных для другой страницы в "boostrap" нет, ведь сервер рендерил только текущую страницу. начинается обычный Flux data flow.

если очень кратко: самые начальные данные клиент берёт из HTML, а дальше всё как обычно, никаких ограничений.

грабли, на которые мы наткнулись практически сразу: неучтённые синглтоны и `on`-подписки вместо `once` на сервере.

результат: расшаренные сессии и сторы между разными клиентами :) следите за этим.

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

~@jsunderhood @listochkin как то говорил в чате что нельзя так, так как экстеншены могут мjдифицировать DOM.

.@olebedev @listochkin буду очень рад узнать альтернативное решение

@jsunderhood Как по мне, тут чейнинг используется только ради чейнинга. Какой профит по сравнению с window.fetch(url, {…})?

.@subzey github.com/matthew-andrew… для любителей.

@jsunderhood на клиенте используете тот же маппинг или другой подход к работе с данными?

.@snejink абсолютно тот же расшаренный маппинг роут -> экшн(ы).

я в целом большой поклонник метода "сделай с нуля, или не поймёшь до конца". но это не значит, что не нужно использовать готовые решения.

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

@jsunderhood есть react native для андроида?

.@kra1g0 afaik нет, но они очень обещают. без чётких сроков, как обычно у Facebook.

@jsunderhood данные для render нужно заранее готовить и в отдельном от React месте. Я вот для этого либу написал bit.ly/1TPnKSn

.@__fro можно в двух словах основной принцип?

@jsunderhood В твитере всё равно поток сознания получается :-) Но в целом всё понятно.

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

в серверный бандл так же можно не включать всё вендорное, чтобы мучать зря файл на пару мегабайт – webpack.github.io/docs/library-a…

@jsunderhood НЕ мучать, идиот.

Надо будет взять кофейку и перечитать @deepsweet в роли @jsunderhood . Не будет какой-нибудь ссылочно-резюмешечного текста по итогам?

@sbmaxx @deepsweet @jsunderhood В профиле аккаунта же есть ссылка jsunderhood.ru

@jsunderhood ого, какая печалька (почитал дальше). Какая-то так себе изоморфность получается. Неужто более лучше ничего нет?

.@silentroach github.com/facebook/react… когда-нибудь…

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

если для чисто клиентского компонента не дёргается экшн в серверном роутере, то он просто отрисуется пустым.

на клиенте в своём componentDidMount() компонент посмотрит, что данных в сторе (от бутстрапа) нет, и сам дёрнет свой экшн. даже изящно.

Вопрос к залу: поддон для посудомойки обязательно нужен? Как подобрать подходящий, какие у них параметры? Забыла заказать вместе с машинкой.

@kra1g0 @jsunderhood стоит ли вообще инвестировать время в него сейчас? есть ли серьезные разработки на нем?

@adaniliuk @jsunderhood @kra1g0 У фейсбука два приложения нативных (ads и groups) - react native. Все очень серьезно.

@jsunderhood Читаю ваши твиты про реакт и не двупляю почти ничего. Чем крут реакт? Киллерфича перед ангуларом? ☺️

@ymatuhin @jsunderhood фича в том, что ты можнешь думать о приложении, как о функции. В математическом смысле слова.

@ymatuhin facebook.github.io/react/docs/why… + jlongster.com/Removing-User-… @jsunderhood

@jsunderhood а если таких компонента два? оба дернут?

.@slonoed мы сделали isRequesting на уровне экшна, чтобы одновременно не было двух одинаковых. всё равно в стор попадёт в одно и то же место

.@slonoed компонент не должен о таком думать

а у кого сейчас какой pet project? :)

появились подвижки в мёрдже isparta в istanbul github.com/douglasduteil/… – покрытие оригинального ES6 кода через sourcemaps от Babel.

к слову, лоадеры к вебпаку для обоих – github.com/deepsweet/ista… / github.com/deepsweet/ispa…

Approaches to testing React components reactkungfu.com/2015/07/approa… – а как вы тестируете реакт-приложения?

у нас (пока) jsdom github.com/tmpvar/jsdom + старая добрая mocha github.com/rstacruz/mocha… + TestUtils facebook.github.io/react/docs/tes…

@jsunderhood используя Shallow Rendering facebook.github.io/react/docs/tes…

@jsunderhood такой же набор + sinon

@jsunderhood ну а дальше mocha, chai с параметром —compilers js:babel/register

@jsunderhood почему не Karma? Для браузера же пишете, jsdom - читерство

.@silentroach а какие именно браузерные отличия ты хочешь тестировать кармой? то, как работает сам реакт? :)

.@silentroach правда. но что это меняет? внутри Flux тоже нечего такого специфичного тестировать… приведи пример, я не могу придумать :)

.@silentroach мы начали с кармы, и на первом проекте она даже до сих пор крутится. даже под Sauce Labs. а потом подумали "а зачем?".

@jsunderhood :) хороший довод. Но проект же состоит не только из реакт-компонентов, правда же?

@jsunderhood так любой js-код. Все же js в ноде от того, что есть в chrome и ff разных версий отличается. Дело же не только в dom.

.@silentroach смотрю на проект и пытаюсь найти что-нибудь такое :) я понимаю о чём ты, но одновременно не попускают мои доводы.

@jsunderhood тот же babel спокойно может зарелизить версию с косяками и зафиксить только через пару часов, какое тут доверие к зависимостям?

.@silentroach по-моему это путь в ад, тестировать "не свой" код. так можно тестировать правильно ли вебпак реквайрит модули, например.

@jsunderhood а это тестировать и не надо, надо тестировать работоспособность своего проекта :) которая может быть сломана зависимостями, да

@jsunderhood насколько я понял и подход и даже частично реализация совпадает с вот этим примером: github.com/erikras/react-…, верно?

.@afitiskin очень может быть, конкретно на это я не смотрел. идея у всех плюс-минус одна.

@jsunderhood получение данных на серверной стороне (наполнение стора) там изящно реализовано, рекомендую обратить на него внимание

@silentroach @jsunderhood так можно же локально тестировать через jsdom, а в CI запускать те же тесты в браузере

@vslinko @jsunderhood @silentroach а как тестировать e2e? Хочу, чтобы перед деплоем основные сценарии проверялись: логин, оплата, ...

@subzey @jsunderhood для fetch получается слишком много лишнего кода типа установки хедеров и тд, в итоге я пришёл к superagent и доволен

@milk_is_my_life @vslinko @jsunderhood @silentroach @jsunderhood мы начинаем прикручивать pioneerjs.com посмотрим , что получится

@adaniliuk @milk_is_my_life @jsunderhood @silentroach я не понял, чем он лучше cucumber.js?

@jsunderhood немного опоздал, но вот небольшой пример isomorphic app (github.com/ShpuntiK/isomo…) с идеями, которые ты описывал (1/2)

@jsunderhood shpuntik.github.io/isomorphic-app… - и презентация на основе этого кода (2/2)

@jsunderhood про синглотоны очень верно :) сам долго осознавал эту проблему

@milk_is_my_life @jsunderhood @silentroach так и тестировать — писать e2e тесты, локально запускають через jsdom, на сервере через selenium

@vslinko @milk_is_my_life @jsunderhood @silentroach хороший вопрос, я пока не знаю. по зависимостям pioneer ссылается на форк cucumberjs.

@adaniliuk @milk_is_my_life @jsunderhood @silentroach понял, это враппер над ним, с e2e API. Но мне больше нравится webdriver.io

Babylon is a JavaScript parser used in Babel github.com/babel/babel/tr…

кажется решились на babel-plugin-typecheck, по крайней мере простые вещи. ненавижу JSDoc. github.com/codemix/babel-… + flowtype.org/docs/quick-ref…

хочется как в Babel – github.com/babel/babel/bl… – комменты комментами, а типы через flow type annotations.

(TypeScript для бедных)

Turn flow type annotations into comments github.com/babel-plugins/…

@jsunderhood Все задаю вопрос почему flow? Почему не typescript?

.@xgrommx а TypeScript уже разве полностью синхронизировался с ES6?

пруф или не было :) RT @roman01la: @jsunderhood @xgrommx уже и с ES7

на сегодня так github.com/mistadikay/rea…, мы над этим работает. RT @roman01la: @jsunderhood У вас своя реализация query в компонентах?

@jsunderhood о-да! Суперагент очень крутой! Я даже написал для него REST-моккер который работает прямо в браузере github.com/rambler-digita…

@jsunderhood Вот их roadmap github.com/Microsoft/Type…

хм, ок. тогда почему не TypeScript?

@jsunderhood он умеет искать по полям в объектах? типа: хочу объект из массива в котором id: 5

.@roman01la да, стандартными средствами Baobab. мы когда осознали, кажется взвизгнули.

github.com/Yomguithereal/… RT @roman01la: @jsunderhood ану покаж!

btw, скоро Baobab@v2 github.com/Yomguithereal/…

@jsunderhood Круто! А как быть с динамическими query? Например листы. Как вы расширяете query?

.@roman01la по ссылке на наш пример видно, что query – это функция, принимающая props и state :)

@jsunderhood Я написал новый ридми для Redux: github.com/gaearon/redux/…. Фидбэк вэлкам! (Доки пока не готовы)

@jsunderhood @roman01la А что о github.com/mquan/cortex скажете?

@jsunderhood @roman01la Вообще есть целый список github.com/enaqx/awesome-…

@jsunderhood Хм, вижу. А что, если часть динамического query зависит от данных из глобального состояния?

.@roman01la ммм… в общем случае оно может быть в пропсах, мы так ID из роута протягивали. ещё вариант – context. есть конкретный пример?

на сегодня это тянется в пропсах, но уже есть кое-какие намёки. RT @roman01la: @jsunderhood вот я про роут и id как раз и хотел сказать :)

@jsunderhood Это не ломает проверку SCU? Или у вас и пропсы и данные по курсору сравниваются в SCU?

.@roman01la не совсем понял как тут сломается SCU. мы сравниваем ID в componentWillReceiveProps и при отличии обновляем свои курсоры.

.@roman01la т.е. данные компонента обновляются на новую ветку с новым ID.

.@roman01la query-функция вызывается заново с новыми пропсами, и получается новый cursor path. ну ты наверное уже понял :)

немного забегая вперёд скажу, что мы уже всё чуть переосмыслили и оформляем в виде небольшого модуля на декораторах. для своих нужд.

а скиньте примеры своего кода на ES6 с JSDoc.

хохма последней недели – "самовозбуждающийся стор"

@roman01la @jsunderhood а почему бы это состояние не хранить в самом tree? )

.@__fro @roman01la именно это мы и собираемся попробовать. в каком-то виде :)

@jsunderhood @roman01la глянул, очень круто ). А это github.com/tonsky/datascr… - следующая итерация идеи @nikitonsky

@jsunderhood я это в своем slt как раз имел ввиду ). Короче, состояние целостно только в случае, когда все причины хранятся в нем же

@jsunderhood и тут основаная моя претензия к flux.Вызов экшена никак не фиксируется,теряются причины.В #redux такая же проблема @dan_abramov

↓ и дальше по реплаям.

JSCity is an implementation of the Code City metaphor for visualizing source code github.com/aserg-ufmg/JSC… 😻

Пс, парень, немного рекурсии не желаешь? pic.twitter.com/tw4p65bqnB

@jsunderhood расскажи вот что про реакт. Как люди валидируют пользовательский ввод в формах, трансформируют его и так далее?

@jsunderhood ибо формы, по-моему, это головная боль на реакте в отличие от того же ангуляря. В ангуляре это прям великолепно сделано

.@iSnifer мы не придумали ничего лучше, чем заюзать validator github.com/chriso/validat… с кастомным выводом ошибок.

.@iSnifer пробовали даже нативную HTML5 валидацию html5rocks.com/en/tutorials/f…, но это просто ад. более невменяемого API я не помню.

тема лично для меня всё ещё актуальная, может есть что-то очевидное и крутое?

@iSnifer @jsunderhood что по поводу github.com/gcanti/tcomb-f… и github.com/insin/newforms?

@iSnifer @jsunderhood tcomb интересный, был небольшой опыт, но newforms поддерживают isomorphic

@iSnifer @jsunderhood А еще в ангуляре есть великолепнейшая либа angular-formly.com

coveralls в read-only, ну круто status.coveralls.io – видимо с этим же связаны последние затупы с pending очередью /@toivonens

.@__fro @roman01la первая попытка, по-моему получилось круто github.com/mistadikay/rea… – cursor path как часть другого cursor path

.@__fro @roman01la до того как делать баобабовый select мы подготавливаем cursor path через рекурсивный поиск вложенных массивов.

.@__fro @roman01la на любой глубине как и раньше могут быть части props/state из функции, в скоупе которой это всё происходит.

@jsunderhood А тогда скажи, форма для тебя должна быть smart- (с внутренним состоянием) или dumb-компонентом (с состоянием в сторе)?

.@mista_k у нас получилось что-то между: у формы есть своё внутреннее состояние, которое можно менять внешними пропсами.

@jsunderhood для валидации форм использую github.com/christianalfon…

Всем привет ) Меня зовут Денис @denisfedosov и люблю верстать. Работаю удаленно в ⚑ Passenger.me.

@jsunderhood а поделись годными материалами про spa (на стек пофиг) :)

@jsunderhood ну ок, кастомный вывод ошибок нормальная тема. А что на счет модификации пользовательского ввода onkeyup? Как $filter в angular

@iSnifer @jsunderhood могу сделать простенький gist для поля ввода номера кредитки, там все очень просто

@jsunderhood @roman01la вроде норм. А в чем смысл использовать state вместо props?

.@__fro @roman01la просто на всякий случай :) у нас такого примера нет, но локальный стэйт компонета всё равно пробрасывается. мало ли.

.@__fro @roman01la а, кажется ты про другое. мы не делали через higher-order component по некоторым причинам, но в целом можно.

.@__fro @roman01la как раз сейчас пишем довольно подробный README. всё будет.

@jsunderhood @roman01la да не, я имел ввиду что вообще нафиг state не нужен ). То есть ну вообще ).

.@__fro @roman01la в идеальном случае – да, согласен. он просто удобен "в виде хранилища" тем, что при обновлении дёргает рендер сам.

@iSnifer @jsunderhood собственно вот: gist.github.com/afitiskin/a65c…

@afitiskin @iSnifer @jsunderhood onchange в Реакте - это только change, или он другие какие-то события подмешивает?

@Chudesnov @iSnifer @jsunderhood любое изменение в input триггерит реактовский onchange, на мобилках должно работать так же

оформили наш подход к работе со стэйтом в реакте github.com/mistadikay/doob, по мотивам поста medium.com/@mistadikay/de… 🔥

@xgrommx @jsunderhood это все какие-то библиотеки, которые подменяют привычное написание элементов форм. Фу на такое

.@iSnifer @xgrommx покажи уже ангуларовый рай для создания и валидации форм

@jsunderhood @xgrommx ща покажу, как раз взялся зафиксировать это

совсем забыл про важную фишку иммутабельности – сохранение ссылок на объекты. простейший shouldComponentUpdate без shallow-equal костылей.

в том же Baobab два курсора на одни и те же данные будут равны через `===`, как и результат их `.get()`а.

@jsunderhood ну просто, для ясности :) вообще да, идея с баобабом заразительна. Особенно то, как это на флакс ложится.

@milk_is_my_life @jsunderhood да не нужен тебе флакс е-мае )). Там же можно на изменения данных подписываться ))

извините, у вас есть минутка поговорить о баобабе? RT @milk_is_my_life: @__fro @jsunderhood точно, не заметил. нафиг флакс, всем по баобабу!

A Virtual DOM based AngularJS view renderer designed to be used with immutable data structures github.com/teropa/angular…

So true

// = "oh hey, by the way,"
/* = "please take a seat."

2:23

в ESLint@1.0.0-rc-3 наконец-то сделали reset по умолчанию eslint.org/blog/2015/07/e…, т.е. нужно заполнять конфиг с нуля вдумчиво и руками.

если вы по какой-то странной причине всё ещё используете JSHint, то самое время перейти с выходом ESLint@1.0.0.

у инструмента, который связан с парсингом ES6, нет практически никаких шансов выжить без Babel. Себастиан не просто так выделил Babylon.

@jsunderhood Так что выжить без Babel для парсинга ES6 очень даже легко (и он будет скорее оверкиллом).

.@RReverser расскажи это какому-нибудь JSCS

@jsunderhood Esprima, собственно, тоже уже догоняет, тем более что общую спецификацию мы уже написали.

.@RReverser на ES7 уйдёт ещё год догонов github.com/estree/estree. парсер Babel хорош именно тем, что он bleeding edge.

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

.@RReverser но на его основе потом и обсуждается формат для ESTree. кому-то нравится теория, а мне нужно использовать ещё вчера.

.@RReverser я начал говорить о конкретных инструментах типа ESLint/JSCS, а ты про глобальное. совершенно очевидно, что есть эсприма и акорн.

.@RReverser про esprima-fb нужно напоминать? :) да, оно когда-нибудь будет стабильное и покрывающее всё-всё. но не сегодня.

.@RReverser вот тебе факты: 1) от JSCS я отказался на следующий день после осознания отсутствия поддержки всего, что мне нужно.

.@RReverser 2) если бы не появился babel-eslint, я бы жил вообще без линтера.

@jsunderhood На чьем формате? Бабеля? Нет. Он в этой сфере относительно недавний игрок, и больше консьюмер чем задающий правила.

@jsunderhood Это не о теории, а о стабильности тулз и фич. Тем более, что все эти ES7 штуки легко реализовать как плагины для акорна.

@jsunderhood Я тоже очень даже о конкретных. ESLint (Espree) мы вон тоже потихоньку на Акорн переводим.

@jsunderhood Не понял посыла про esprima-fb. В том-то и суть, что стабильным оно может и не стать, и быть по-тихому удалено с ядра.

@jsunderhood Это основная политика Бабеля - можно экспериментировать с новыми фичами, но мы их в любой момент можем убрать.

.@RReverser ты снова про какую-то абстрактную теорию. у тебя есть живой проект на ES6/ES7, который нужно, например, линтить? похоже, что нет

.@RReverser можно сколько угодно обсуждать инструмент в вакууме, но если бы не появился babel-eslint, ваш "ESPree" до сих пор бы тужился.

@jsunderhood Ладно, это бессмысленно :( В который раз описываю как конкретно это работает прям сейчас изнутри, а ты называешь теорией :(

@jsunderhood babel-eslint - временный хак, в том числе Себ это признает и хочет изменить в сторону стандартов. Он крут, но все же временный.

.@RReverser я ни разу это не отрицал, если ты не заметил. временный, НО АКТУАЛЬНЫЙ. это куда важнее для проекта, который УЖЕ ЕСТЬ.

.@RReverser Esprima и Acorn без сомнений сделают полную поддержку ES6 и даже ES7. но когда? сколько месяцев мне ещё не использовать тулзы?

@jsunderhood Прочти первый свой твит из которого собственно все началось :)

.@RReverser сегодня у инструментов всё ещё мало шансов. что не так-то? JSCS переводят на babel-jscs просто так?

.@RReverser как итог – у тебя бомбануло не по теме :)

@jsunderhood Аргументировал достаточно, и почему ES6 тулзам Babel как парсер вообще не критичен, а ты в ответ начал мне про эксперименты :)

.@RReverser дай мне рабочие ESLint и JSCS без Babel. аргументировал он :)

@jsunderhood Ммм... я среди тех, кто это в том числе строит в тимке Babel-а.

.@RReverser такие аргументы никогда не волновали и не будут меня волновать вообще никак :) будь ты хоть Крокфордом.

@jsunderhood Очень рад, что человек, использующий тулзы, обясняет, как надо строить эти самые тулзы :) Удачи!

.@RReverser когда придумаешь ответ на мои доводы про ESLint и JSCS, приходи. я как не мог их толком использовать полгода назад,так и не могу

.@RReverser пока ты скатился только "а я авторитет, и кажется знаю, о чём говорю"

спор математика и инженера, блин.

@jsunderhood Та да. Причем, почему-то кажется, каждый из нас видит математика в другом :)

@jsunderhood а в чем принципиальные отличия, чтобы прям взять все бросить с перейти?

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

.@tvii всё бросать сразу точно не стоит, но попробовать – однозначно.

@jsunderhood а есть смысл переходить, если пишешь на es5 и не на react? мне это видится переходом ради перехода

.@baxxabit помимо ES6 и прочих JSX смысл есть уже просто потому, что это новое поколение знакомого инструмента eslint.org/docs/rules/

@baxxabit @jsunderhood можно новое начать писать на ES6

@baxxabit @jsunderhood А причём тут React?

.@freiksenet @baxxabit заметили, как мощно React/JSX зафорсили ES6, что иногда даже одно без другого уже кажется странным? :)

(по большому счёту и JSCS не нужен, codestyle-правил в ESLint по крайней мере для меня уже достаточно)

(с одной стороны, разделение обязанностей это хорошо, с другой – два разных инструмента это слишком)

btw, husky – "Prevents bad commit or push (git hooks, pre-commit, pre-push and all that stuff…)" github.com/typicode/husky

когда кто-то всерьёз говорит "ES2015" вместо "ES6" [gif] replygif.net/i/100.gif

перестал следить за Node.js + io.js с момента анонса "foundation". что там? мёрдж? роадмапы?

homebrew-rmtree – remove a formula and its unused dependencies github.com/beeftornado/ho…

@jsunderhood привет! вы проверяете в компонентах propTypes? если да, то есть какой-то регламент (что проверять, насколько глубоко и тд)?

.@alexfedoseev привет. по-хорошему конечно нужно проверять :) это даже ни столько для валидации, сколько для наглядного представления данных

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

(мы даже сделали в Yummies безумный экстенд отдельных файлов с propTypes по слоям, но пока так ни разу не воспользовались)

был хороший issue в тему github.com/facebook/flow/… – propTypes на фоне нормальной типизации кажется костылём, хоть в нём и есть свои фишки.

(Flow, конечно, хорош, но он статический "типизатор". по поводу динамической типизации я всё ещё верю в штуки типа github.com/codemix/babel-…)

@jsunderhood сон не нужен? (:

.@Kern_0 у меня уже почти 10 утра

задумка простая: перед тем как удалять, превращать все flow types annotations в инлайновые ассерты. только в dev-режиме, конечно же.

@jsunderhood и да, typescript тащит!

@backendsecret @jsunderhood @rubyunderhood думаю, картинка будет полезна pic.twitter.com/6tkRlf8CqN

1/6 A young developer approached me after a conf talk and said, “You must feel really bad about the failure of object-oriented programming.”

2/6 I was confused. I said, “What do you mean that object-orient programming was a failure. Why do you think that?”

3/6 He said, “OOP was supposed to fix all of our software engineering problems and it clearly hasn’t."

4/6 He continued: "Building software today is just as hard as it was before OOP. came along.”

5/6 I said: “Have you ever look at the programs we were building in the early 1980s? At how limited their functionality and UIs were?”

6/6 OOP has been an incredible success. It enabled us to manage complexity as we grew from 100KB applications to today’s 100MB applications.

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

это точно устаканится в каком-то своём правильном балансе, но хотелось бы, чтобы сам процесс в целом не останавливался никогда.

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

(я разлогинюсь где-то в 19 по МСК, если осталось что обсудить или спросить – самое время)

@jsunderhood когда месяц - это хорошо или плохо?

.@RusAlexander "минус" – постоянная тяга к рефакторингу. если откровенно запустить, то будет плохо, и не только тебе самому.

.@RusAlexander если подойти осознанно и извлечь из этого свои плюсы, то можно действительно улучшить код не просто ради факта переписывания.

@jsunderhood ну ведь принцип "работает не трогай" всегда останавливает от преждевременного рефакторинга.

.@RusAlexander как я заметил, это довольно сильно зависит от проекта. есть такие, где даже думать о рефакторинге нельзя, чтобы не сломать.

.@RusAlexander "преждевременный рефакторинг" – это подростковость :) и рано или поздно проходит, сам таким был ещё недавно.

@jsunderhood у меня под это определение попадает любой рабочий и приносящий доход проект

.@RusAlexander именно поэтому я и говорю, что зависит от проекта. можно сопротивляться сколь угодно, то всё равно придётся разделять […]

.@RusAlexander […] "бизнес" и "гик". на каком-то этапе стартапа может показаться, что это одно и то же, но это ловушка.

@jsunderhood согласен. Но ту точку где рефакторинг необходим, нам надо как-то обозначить в этом треде

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

.@RusAlexander если ОЧЕНЬ сложно вносить изменения в работающий проект, то нужно хотя бы подумать о том, чего будет стоить новая архитекрута

.@RusAlexander *иногда* в это удачно можно вплести "бизнес", аргументировав тем, что затраты на поддержку в текущем виде дороже рефакторинга

учусь определять зрелость разработчика (как человека в том числе) по его код-стайлу. в этом есть свои отчётливые закономерности.

@jsunderhood вот здесь полностью согласен. Рефакторинг ценен только тогда когда ты вносишь требуемые изменения в проект.

это отражение внутреннего состояния, как если бы вы рисовали картины для психолога. и программиста-подростка,которому уже за 30, сразу видно

@jsunderhood Какие?

.@gxoptg_ умение думать о других. не тупо "специально" писать слишком вербозный код, а иметь как личное качество на привычном обычном уровне

.@gxoptg_ обилие вложенных тернарных операторов и прочие однострочники от тех, кто не наигрался в своё время на 140byt.es

.@gxoptg_ отсутствие даже единственной строчки с комментарием под предлогом "нормальный программист и так поймёт".

@jsunderhood однажды я добавлял на страницу кнопку больше недели.

@jsunderhood А как от такого избавляться?

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

самый треш – "кто не понял как работают мои выглядящие как перл три строчки кода, тот тупой и просто не дотягивает до моего уровня".

@sevaisnotcow @jsunderhood как объяснили это заказчикам, если это был enterprise ?

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

@RusAlexander @jsunderhood это был крупный соцсервис, с миллионом а/б тестов, из за них это и произошло, и из за отсутствия чего то типа бэм

@RusAlexander @jsunderhood кнопочку то я вставил быстро, неделю я делал так что бы она одинаково везде работала

чаще всего такие люди физически не способны доводить начатые проекты до конца, т.к. одно дело набросать прототип с однострочными while [...]

[…] циклами без "лишних скобок", а другое дело жить с этим, думать про внешний API и т.п… быть ответственным, вот.

вспомните своих коллег, у каждого такой есть :)

@sevaisnotcow @jsunderhood ха. у нас на поддержке старый гос. интерпрайз. Кнопочку туда месяц как-то вставляли.

Я КНОПОЧКУ ДО СИХ ПОР ВСТАВЛЯЮ, УЖЕ 30 ЛЕТ ЖИВУ.

@RusAlexander @jsunderhood если рефакторинг снижает стоимость владения продуктом в дальнейшем, то вот и точка.

@jsunderhood вот глянул код полугодовалой давности..

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

@jsunderhood Причем всегда известно, какие есть опции по улучшению/изменению. Но чаще объективных причин менять нет.

@jsunderhood код должен быть выразительным и без мусора.

@jsunderhood Даже очень краткий код может быть хорошо понимаем без комментариев (при достаточной квалификации)

.@__fro может, когда это действительно искусное владение. а может и нет, когда это 1) самоцель 2) ЧСВ

.@__fro причины-то понятны. я наверное больше про то, что я пока ещё явно не постиг все паттерны и не всегда умею писать сразу "правильно".

@jsunderhood и такое бывает )). По себе знаю, иногда приходится бороться с порывами повыпендриваться ).

@jsunderhood иногда нужно просто отложить вставлялку в сторону и отпустить в продакшен.

@vladimore @jsunderhood если любишь отпусти

@jsunderhood надо перестать заморачиваться, оно само придет ). Главное грамотная постановка задачи (тесты), а способ найдется.

.@__fro вот трушный TDD – пока мечта. это явный показатель очень высокого уровня.

@jsunderhood @__fro Вот да, всегда уважаю людей которые могут понять задачу до написания кода, чтобы на неё написать тесты.

@freiksenet @jsunderhood это и есть итеративный подход. Нет идеальной схемы, это как лепка из пластилина )

@__fro @jsunderhood Ну вот похоже скилл программиста это сколько тебе надо итераций, чтобы сделать правильно какую-то фичу.

@__fro @jsunderhood Правильно - это чтобы соответствовало внешним требованиям и не сгнило после того как они совсем поменялись.

@jsunderhood к сожалению, в коммерческой разработке инженеру не доносят задачу цельно. Поэтому и цель размывается. И качество страдает (

@freiksenet @jsunderhood А вот те, кто не мыслит итерациями, на самом деле они находятся внутри одной бесконечной итерации ))

.@__fro @freiksenet так, у нас тут один словил МакКонахи, вызывайте помощь.

@freiksenet @jsunderhood то есть профессионалу нужно смириться со своим несовершенством и только тогда выйдет что-то стоящее

а как вам такое – "преждевременный отказ от копипасты"

@__fro @freiksenet @jsunderhood мне помогли в этом книги о физиологии мозга. Ошибки - обязательная часть обучения.

@jsunderhood преждевременный отказ от говнокода

@vladimore @__fro @jsunderhood Да меня не пугают мои ошибки, меня восхищают люди которые их делают меньше чем я при схожей продуктивности.

.@mistadikay оттягивание коммита "it just works"

@jsunderhood проблема большинства программистов - инфантелизм. Отсюда и бескончные размышления о коде как о высшей ценности.

pic.twitter.com/6uDrgh3c4Y

@jsunderhood pic.twitter.com/AoqHwjWsKr

@jsunderhood когда N обработчиков с 80% копипаста лучше, чем один обработчик c декларацией параметров для них ?
jsfiddle.net/trnt/savrdygy/

.@apostololeg когда один обработчик становится слишком полиморфным и сложным

@jsunderhood Мастерство, это когда не только сам пишешь хорошо, но когда ты senior, и все в команде пишут как надо (пусть не с первого раза)

@jsunderhood Как делать TDD на фронтенде? И вообще как хорошо тестировать фронтенд?

.@freiksenet karma + mocha + chai + sinon

.@freiksenet + istanbul. dev-режим с вотчером в карме прекрасен, как раз для вывода на отдельный монитор при TDD.

@jsunderhood Ну технологии я знаю. Меня интересует процесс, как сделать тест не имея ещё, например, реакт компонента.

@jsunderhood Насколько полезно мерить code coverage? Мы не меряем, хотя и стараемся хорошо тестировать и требовать тесты в ревью.

@jsunderhood Что нам даст code coverage?

.@freiksenet даст понимание, какие условия, циклы и даже целые методы не покрыты тестами вообще никак.

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

.@freiksenet задрачивать покрытие на 100% рационально разве что на небольших проектах. задача №1 – убедиться, что покрыто то, что должно.

ну или если это действительно критично github.com/babel/babel/is…

.@freiksenet код Babel довольно сильно меняется, отсюда потребность сразу видеть то, что из нового или переделанного старого не покрыто.

.@freiksenet т.е. тесты после рефакторинга могут и не валиться, но это ещё не идеальный результат.

прикрутить покрытие тестов к нормальному проекту можно и за полчаса, а *потенциальный* профит куда круче.

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

чем умнее программист, тем тупее его функции pic.twitter.com/Fw3a6BSZqk

@jsunderhood нормальному?

.@superv1s0r ну в смысле прикрутить к проекту новый инструмент не составляет труда :) бывает же всякое.

@jsunderhood @freiksenet что про tape думаете/знаете?

.@illbullet @freiksenet знал, что он есть, и что это в каком-то смысле альтернатива mocha. вот пошёл читать подробно medium.com/javascript-sce…

.@illbullet @freiksenet а можно преимущества в своих двух словах?

@jsunderhood помню, как один БЭМ-разработчик, слово в слово такое выдавал.

.@mostolovista потом его конечно в дурку забрали?

@jsunderhood о, да! Однажды я решил что ифы не нужны — есть же тернарки. Потом правда одумался, но 2 проекта так написал @gxoptg_

.@shuvalov_anton @gxoptg_ pic.twitter.com/mXDcV16Huk

эту забавную неделю с вами был @deepsweet. надеюсь, что было интересно, спасибо всем за общение :) логи будут здесь jsunderhood.ru/deepsweet

часто говоря "мы" я имел в виду себя и @mistadikay – моего коллегу, напарника по парному программированию и просто хорошего трансгендера.

@jsunderhood в штанах у тебя трансгендер

так и живём :)

ещё увидимся в каком-нибудь cljsunderhood. логаут.