но не знаю насколько продвинулся

basic-streams?

да

ну и он писал что придумал как еще ускорить кефир, но смысла нет — получится most

кто нибудь имел дело с параллелелизацией JSON.parse JSON.stringify в node.js? нужно быстро спарсить\сохранить ~30mb данных. Структура одинаковая. Как проще по тредам это разделить? какой IPC проще реализовать?

Golang? :)

ну такто любой язык с тредами подойдет. только как это все из node.js достать? :)

@DenisElistratov

кто нибудь имел дело с параллелелизацией JSON.parse JSON.stringify в node.js? нужно быстро спарсить\сохранить ~30mb данных. Структура одинаковая. Как проще по тредам это разделить? какой IPC проще реализовать?

Вы сговорились с Кристофером? ) Он такую же задачу решает https://twitter.com/cpojer/status/721958592933289986 И в треде ответы неутешительные... Там есть 1 здравая идея: не пытаться парсить всё сразу, а делать lookup on-demand — но это если задача позволяет. Кристоферу — нет, ему надо все данные сразу,

ну мы одну и туже задачу решаем :)

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

но так как тут время меньше секунды, то типичный нодовский подход с кучей процессов не пойдет

Тот же transit.js написан поверх JSON.parse. Все кастомные алгоритмы от лукавого, не обгонят хорошо оптимизированный C++ код JSON.parse. Разве что регулярками парсить, и заложиться на простоту структуры, например flat-массив — RegExp в V8 оптимизированы едва ли не лучше чем JSON.parse...

не. ну с алгоритмами понятное дело тягаться не вариант :)

я больше думаю в сторону разделения этого 30mb файла на 100 кусков и сборки их отдельно

может получится от 500 до 200~ снизить

но не знаю в какую сторону идти. сейчас пишу jruby скрипт который из node вызывается

.in vs .biz vs .co.uk vs .org.uk vs .org vs .com vs .net vs .azurewebsites.net

но не знаю в какую сторону идти. сейчас пишу jruby скрипт который из node вызывается

Коллега про go истину глаголил. Все же быстрее на нем будет

Если дочерним процессом вызвать

была хорошая либа для этого, пытаюсь вспомнить название

http://oboejs.com/

HTTP авторизация

только что-то не обновлялась давно

Еще есть какая то либа со стримящим парсером json

Ага, Relay ?

написал FFI модуль на Rust. не спасло... оверхед большой на гоняние данных из нэйтива в node :)

Привет

Как красивее всего удалит свойство из объекта по ключу?

delete?

var obj = { val: 1 }; obj.val = undefined;

https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Operators/delete

я бы не сказал что это удаление

delete тормозной

я бы показал вам jsperf, но он не работает

delete object.key;

красивее не найти)

ну, я не думаю, что ему надо удалить 20 тысяч ключей

за секунду)

Спасибо. В поисках красоты совсем забыл про delete

https://jsbench.github.io/#78e5b999c39a11837e32b0635de581cc

ну да, экономия такая никому не нужна)

Вы забываете, что obj.val = undefined не удаляет свойство. Оно остается итерируемым. Просто присваиваете значение undefined

Добавляю элементы html после загрузки страницы. Как повесить обработчик на вновь добавленные элементы?

Потом не споткнитесь только

Наверное только путем отписки и повторной подписки

Добавляю элементы html после загрузки страницы. Как повесить обработчик на вновь добавленные элементы?

Event delegation. Ставь обработчик на родителя.

Event delegation. Ставь обработчик на родителя.

Спасибо за наводку

Получается можно повесить на body и проверять e.target на className, к примеру

И все обработчики красиво в одном месте без addEventListener

так реакт и делает напрмер

круто

Формирую так таблицу. Может подскажите как по уму?

Сори, что тут React нет )))

Возможно стоит использовать jsx в отрыве от реакта?

если такого немного, то я предпочитаю не стрелять из пушки по воробьям)

Формирую так таблицу. Может подскажите как по уму?

Я бы натравил eslint, и еще говорят что производительнее джоинить массив, а не конкатенировать строки

и всё летит к чертям, когда cart = null =) почему не заюзать шаблонизатор какой-нибудь простенький хотя бы?

и всё летит к чертям, когда cart = null =) почему не заюзать шаблонизатор какой-нибудь простенький хотя бы?

+

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

А то выйдет как тут

https://s3-eu-west-1.amazonaws.com/uploads-eu.hipchat.com/60030/2360982/UXpQe6QH8tyg3W4/IMG_20160418_002334.jpg

ERROR: S client not available

Я бы натравил eslint, и еще говорят что производительнее джоинить массив, а не конкатенировать строки

Согласен

и всё летит к чертям, когда cart = null =) почему не заюзать шаблонизатор какой-нибудь простенький хотя бы?

С чего бы ему быть null?

ну мало ли)

Ну там строка ожидается видимо. Можно в try/catch обернуть этот блок с JSON.parse, поскольку заведомо все равно не ясно валидна ли будет строка

есть разница как получать localStorage. Если localStorage.getItem('test') будет null, то localStorage['test'] будет уже undefined

Ну там строка ожидается видимо. Можно в try/catch обернуть этот блок с JSON.parse, поскольку заведомо все равно не ясно валидна ли будет строка

Так по-хорошему надо всегда и везде делать ))

Так по-хорошему надо всегда и везде делать ))

Всегда оборачивать в try/catch?

Ну не всегда это уместно. Если ты понимаешь какой тип ты ожидаешь, то достаточно проверить на тип. Но строка, которая не понятно будет ли json, без try/catch может просто вылететь.

Я так понимаю, что если получаешь данные извне, то надо проверить и бросить исключение если что

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

Непонятно просто из кода откуда вообще этот cart прилетает.

Он то сломаться может не только если там null. Что угодно, что не сможет стать на выходе объктом. И тогда JSON.parse бросит исключение, который не перехватывается.

Прилетает из localStorage

Знатоки редукса, подскажите, норм ли иметь некоторые компоненты со своим стейтом, типа тултипа?

нормально

Знатоки редукса, подскажите, норм ли иметь некоторые компоненты со своим стейтом, типа тултипа?

да

Ок, спс

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

Я бы натравил eslint, и еще говорят что производительнее джоинить массив, а не конкатенировать строки

Я тут как-то твитил на эту тему: https://twitter.com/denisizmaylov/status/715266866118266881 Иными словами, сейчас JavaScript слишком быстрый (если мы не берем задачу в реальном времени обрабатывать 25-мегабайтный JSON ;)), чтобы увлекаться такими хаками. Проблема с опытными разработчиками куда острее. Они смогут не понять все эти хаки и будет потеря времени при понимании кода. Плюс его портабельность снижается. Поэтому лучше использовать стандартные (delete, indexOf и тд), пусть VM заботится об оптимизации.

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

а в чем проблема?

ну у них разные состояния должны быть

Я тут как-то твитил на эту тему: https://twitter.com/denisizmaylov/status/715266866118266881 Иными словами, сейчас JavaScript слишком быстрый (если мы не берем задачу в реальном времени обрабатывать 25-мегабайтный JSON ;)), чтобы увлекаться такими хаками. Проблема с опытными разработчиками куда острее. Они смогут не понять все эти хаки и будет потеря времени при понимании кода. Плюс его портабельность снижается. Поэтому лучше использовать стандартные (delete, indexOf и тд), пусть VM заботится об оптимизации.

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

хранить в state компонента? а какже тогда единый store с редусерами)

или как-то динамически редусеры создавать... под компонент...

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

ну к примеру карусель, их несколько на странице

у каждого компонента есть состояния, такие как позиция текущая

ну такие вещи лучше в стейте компонента держать

если их состояния важны для внешних компонентов, то в сторе, если нет – то в стейте компонента

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

Я воспринял твое сообщение, как использовать ['a', 'b'].join('') или ты что-то другое предложил? :)

ну а как в сторе лучше хранить тогда