да, мне нужно именно ждать

это чтения с диска

я не хочу чтобы у меня 50 тыс файлов одновременно читалось с hdd, например)

кажется, тут нужен хитрый scan

А вообще не

нужно создать Observable для получения тегов и использовать его

да, он у меня есть: fromPromise :)

нужен https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/operators/startasync.md

fromPromise принимает готовый промис, а тут асинхронная функция которую нужно вызывать в определённый момент

то есть там .concatMap(file => $.startAsync(() => getMediaTags(file))

А твой вариант (который вроде сводится к `concatMap(getMediaTags)`) работает?

Потому что вообще-то concatMap понимает промисы

https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/core/operators/concatmap.md

concatMap ожидает синхронную функцию

вот это вот неправда

вот это вот неправда

да)

в chain попадет асинхронно, сам resove может быть вызван синхронно

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

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

ну я имел ввиду тело промиса вызов resolve ведь таки в теле промиса

у вас там может быть setTimeout(resolve)

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

если точнее, в конце текущего тика

window.setTimeout(() => console.log(1), 0); Promise.resolve().then(() => console.log(2)) console.log(3) // 3 // 2 // 1

если точнее, в конце текущего тика

https://github.com/nodejs/node/issues/2736

если нужны хардкорные детали

Все мы любим функциональное программирование, но надо двигаться дальше. Как насчет — только не пугайтесь — функционального CSS? Если коротко, это подход, основанный на переиспользуемых базовых классах для каждого свойства; самые известные библиотеки это Basscss и Tachyons. Шу Уесуги (Shu Uesugi) из команды edsurge собрал в одном эссе «что и почему» подхода. Мы у себя в редакции пока не разобрались, взлетит или нет — а как вы думаете? https://github.com/chibicode/react-functional-css-protips

Как тебя туда занесло ?

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

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

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

Какие проблемы самые проблемные будут?)

Медиа запросы, составные селекторы - без них никуда, всегда придется дописывать стили, строка выходит за рамки адекватного количества символов, пропадает возможность critical css, он весь получается критикал, нет возможности изменить свойства селекторов, нужно править весь код где нужно это измененное свойство ну и ряд других менее значимых проблем

Еще наверное одна из критических это специфичность селекторов от позиции, ее решение увеличивает наш файл в десятки раз

Медиа запросы, составные селекторы - без них никуда, всегда придется дописывать стили, строка выходит за рамки адекватного количества символов, пропадает возможность critical css, он весь получается критикал, нет возможности изменить свойства селекторов, нужно править весь код где нужно это измененное свойство ну и ряд других менее значимых проблем

У меня для решения части этих проблем stylus

Так что теперь даже интереснее попробовать)

Оно не решает ни одной проблемы

Хотя да

Ну ты отчасти прав, я в тот момент перешел на сасс и начал генерировать такие стили скриптами

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

В stylus есть nib, только сейчас понял, что оказывается давно пользуюсь функциональным css ?

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

Я вот как раз не могу понять, как я к этому отношусь. С одной стороны реально здравое зерно есть, но с другой %)

Я в свое время выбрал постцсс который реализовывал вложенность, больше ничем особо и не пользуюсь, сейчас полностью на css in js перешел который решает наверное все основные проблемы цсса

Как тебя туда занесло ?

в CodeHipsters?)

вот что надо использовать https://github.com/blakeembrey/free-style

https://github.com/ajoslin/stylin

Чет никогда не понимал смысл делать css в js

все то же: композитность, переиспользуемость, гибкость и т.п.

как, например, проще всего шарить (совместно использовать) переменные между css и js?

из css-in-js мне самыми интересными показались jss & cssx

как, например, проще всего шарить (совместно использовать) переменные между css и js?

лучше css written with js)

каррирование это вам не category theory

https://www.infoq.com/presentations/category-theory-propositions-principle

https://github.com/bodil/eslint-config-cleanjs

Отступы в JavaScript-коде. Кто что использует? 2 пробела – 139 ??????? 55% Tab – 72 ???? 28% 4 пробела – 39 ?? 15% Другое – 3 ▫️ 1% ? 253 people voted so far.

То, что уже есть в проекте)

Это жизнь)

еще про точку с запятой надо спросить)

еще про точку с запятой надо спросить)

Вот тут кстати наверное уже не такой очевидный расклад будет)

Но точки с запятой вообще не нужны)

не нужны

нужны

А зачем писать что-то ниже return?

Когда нужны, тогда и можно поставить, одну на весь файл

А зачем писать что-то ниже return?

не нужно

А где ещё ; что-то меняет?

Понятно, что тут имеется в виду конец строки, а не условия цикла

нужны

привычка свыше нам дана замена счастию она

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

А нет случайно отдельного чатика по elm-у ?

А нет случайно отдельного чатика по elm-у ?

чатика верод бы нет, номожешь начать здесь

https://www.youtube.com/watch?v=dkZFtimgAcM

Поправьте если я ошибаюсь но поскольку в elm-е records не могут иметь ссылки на себя (прямо или косвенно через другие) то это вынуждает нас моделировать стейт в виде плоского хеша таблиц а любые связи через айдишники - например {children = ['id121', 'id3232'], parent = 'id3434'} вместо обычных ссылок на объекты

Что у нас тут нет элмистов?

даже женщины уже в элме https://www.youtube.com/watch?v=cgXhMc8M4X4

вот пока нашел единственный курс по эльму http://courses.knowthen.com/courses/elm-for-beginners

Что у нас тут нет элмистов?

А зачем элм нужен?

Какой профит?

Какой профит?

один из вариантов перехода к ФП на фронте

https://www.youtube.com/watch?v=7Zlp9rKHGD4

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

что значит "моделировать связи" и чем мешает иммутабильность?

что значит "моделировать связи" и чем мешает иммутабильность?

Пример - нам нужно обновить допустим название таска. Согласно иммутабельности мы не можем изменить объект мы должны вернуть новый. Ок, вернули новый. Но таск то не находится в стороне - у таска есть массив сабтасков - у этих сабтасков есть поле parent с ссылкой на таск и также у поста есть поле tasks с массивом ссылок на таски. И также у юзера есть поле созданных тасков. И когда мы вернули совершенно новый объект таска все эти связи с ссылками будут то указывать на старый таск - значит нам нужно также обновить (вернуть новую версию) и все объекты которые имеют ссылку на этот таск, но эти объекты в свою очередь имеют другие связи и все рекурсивно приведет к тому что нам прийдется перегенерировать и вернуть абсолютно новый граф объектов состояния

а это приведет к тормозам

Если вы это все на фронте делаете, то тут что-то не так.

Пример - нам нужно обновить допустим название таска. Согласно иммутабельности мы не можем изменить объект мы должны вернуть новый. Ок, вернули новый. Но таск то не находится в стороне - у таска есть массив сабтасков - у этих сабтасков есть поле parent с ссылкой на таск и также у поста есть поле tasks с массивом ссылок на таски. И также у юзера есть поле созданных тасков. И когда мы вернули совершенно новый объект таска все эти связи с ссылками будут то указывать на старый таск - значит нам нужно также обновить (вернуть новую версию) и все объекты которые имеют ссылку на этот таск, но эти объекты в свою очередь имеют другие связи и все рекурсивно приведет к тому что нам прийдется перегенерировать и вернуть абсолютно новый граф объектов состояния

Бред

один из вариантов перехода к ФП на фронте

В чем профит элма? Кроме того явного - типы и компиляция.

один из вариантов перехода к ФП на фронте

Про ФП можно не говорить. Мне интересен профит от инструмента. Элм - инструмент.

Пример - нам нужно обновить допустим название таска. Согласно иммутабельности мы не можем изменить объект мы должны вернуть новый. Ок, вернули новый. Но таск то не находится в стороне - у таска есть массив сабтасков - у этих сабтасков есть поле parent с ссылкой на таск и также у поста есть поле tasks с массивом ссылок на таски. И также у юзера есть поле созданных тасков. И когда мы вернули совершенно новый объект таска все эти связи с ссылками будут то указывать на старый таск - значит нам нужно также обновить (вернуть новую версию) и все объекты которые имеют ссылку на этот таск, но эти объекты в свою очередь имеют другие связи и все рекурсивно приведет к тому что нам прийдется перегенерировать и вернуть абсолютно новый граф объектов состояния

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

Пример - нам нужно обновить допустим название таска. Согласно иммутабельности мы не можем изменить объект мы должны вернуть новый. Ок, вернули новый. Но таск то не находится в стороне - у таска есть массив сабтасков - у этих сабтасков есть поле parent с ссылкой на таск и также у поста есть поле tasks с массивом ссылок на таски. И также у юзера есть поле созданных тасков. И когда мы вернули совершенно новый объект таска все эти связи с ссылками будут то указывать на старый таск - значит нам нужно также обновить (вернуть новую версию) и все объекты которые имеют ссылку на этот таск, но эти объекты в свою очередь имеют другие связи и все рекурсивно приведет к тому что нам прийдется перегенерировать и вернуть абсолютно новый граф объектов состояния

да это похоже на непонимание вообще что такое иммутабильность

Про ФП можно не говорить. Мне интересен профит от инструмента. Элм - инструмент.

смотря относительного чего профит

смотря относительного чего профит

Чем elm хуже/лучше/краше/моднее js"а? Например

В чем профит элма? Кроме того явного - типы и компиляция.

Кроме компиляции

Чем elm хуже/лучше/краше/моднее js"а? Например

Js это не функциональный язык, вы каким образом подоходы ФП реализуете на JS?

Как и всегда, каррирование, partial application, суперпозиция функций, унификация абстракций, работа с коллекцией.