Как пример можно приписывать дату к объектам при добавлении их в стор. И при критическом объеме стора, вычищать старые объекты.

Как пример можно приписывать дату к объектам при добавлении их в стор. И при критическом объеме стора, вычищать старые объекты.

это очень не надежно

да и какую дату? я например могу старые сообщения смотреть

если только сделать какую то обертку и делать mapStateToProps через нее

и записывать ts маппинга

@gusnkt ты же вроде мессенджер пишешь? :)

Угу

Угу

А расскажи ваше датафлоу с данными, как их подчищаете

храните ли все сообщения нормализованными?

Ох, там сложно) у нас есть сервер, есть протокол и клиентская либа на Java, которая под платформы компилится. Там вся работа с данными и проходит

Ох, там сложно) у нас есть сервер, есть протокол и клиентская либа на Java, которая под платформы компилится. Там вся работа с данными и проходит

мне только клиент)

мне сервер не интересен

что делаете, чтобы за неделю работы с открытым табом, браузер не сдох)

так вот вся работа с данными в библиотеке происходит, а flux+react только отрисовывает, в основном

профилирование и отлавливание утечек памяти?

так вот вся работа с данными в библиотеке происходит, а flux+react только отрисовывает, в основном

т.е. ничего не нормализуете? все сообщения в какой то одной переменной (массиве) хранятся в сторе?

по сути да

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

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

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

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

чтобы был split-screen?

да

вообще мы можем такое сделать)

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

вообще на сколько я знаю, как у нас реализовано. При старте приложения клиент получает все группы и всех юзеров, с которыми есть чаты. При такой логике сообщения скорее всего могут приходить с id sender, а не полным объектом. Ты про эту нормализацию?

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

А сейчас react-id как-то узнать можно? В DOM уже не видно, в RDT тоже не нашел

Правильно ли я понимаю, что есть такая ситуация. В сторе хранятся сообщения следующим образом: messages: {[id: string]: Message} При этом хочется иметь какой-то мусоросборщик который ограничивал бы максимальное количество сообщений в сторе?

Руслан, зачем вообще может потребоваться знать react-id?

я могу 1 применение точно придумать. react-addons-perf

Да, изучал лог printOperations, хотел проверить причину изменения атрибутов

printOperations из react-addons-perf

printOperations - это бывший printDOM

в логах есть куча операций типа 993 "202" "remove attribute""["disabled"]" 994 "202" "update attribute""["disabled",false]" 995 "203" "remove attribute""["selected"]" 996 "203" "update attribute""["selected",false]" 997 "203" "update attribute""["value",307]" 998 "203" "remove attribute""["disabled"]" 999 "203" "update attribute""["disabled",false]"

Правильно ли я понимаю, что есть такая ситуация. В сторе хранятся сообщения следующим образом: messages: {[id: string]: Message} При этом хочется иметь какой-то мусоросборщик который ограничивал бы максимальное количество сообщений в сторе?

Не ограничивал, а подчищал не нужные (которые не используются в UI)

Довольно интересная задачка получается (:

У каждого сообщения должен быть счетчик во скольких вьюшках оно используется. При достижении счетчика нуля, необходимо удалить его из стора. Надо будет заморочиться за такую штуку (: Спасибо за идею! Буду думать

У каждого сообщения должен быть счетчик во скольких вьюшках оно используется. При достижении счетчика нуля, необходимо удалить его из стора. Надо будет заморочиться за такую штуку (: Спасибо за идею! Буду думать

можно не удалять а переносить в localStorage например

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

ну вот у нас такая проблема была как раз)

хорошо бы сразу закладывать асинхронность

тогда можно с localStorage переключиться на indexedDB/WebSQL

но indexedDB - это IE10+, если это важно

fallback - localstorage

Не ограничивал, а подчищал не нужные (которые не используются в UI)

для этого должна быть логика частичного восстановления стейта из внешнего хранилища (стейта), а это в общем случае очень нетривиально делать эффективно. Есть у тебя три сообщения [msg1,msg2,msg3], первое и третье испольуется, второе нет, ты его удалил, потом скролл проехал и внезапно тебе его надо показать. И ты в общем случае не знаешь, сколько их там, почищенных - одно или 800. и таких "дырок" в данных может быть много. и разнообразных данных и коллекций тоже. Оно будет достаточно сложно даже на примитивных данных, не говоря уже о сложном приложении. Подход утопичен, имхо. В качестве оптимизаций в конкретных кейсах можно, но там обычно находятся гораздо более простые варианты. Идея сохранять в ls/indexdb выглядит прикольной но бессмысленной ) неясно, чем там лучше хранить данные чем в стейте аппы непосредственно в js-объектах

для этого должна быть логика частичного восстановления стейта из внешнего хранилища (стейта), а это в общем случае очень нетривиально делать эффективно. Есть у тебя три сообщения [msg1,msg2,msg3], первое и третье испольуется, второе нет, ты его удалил, потом скролл проехал и внезапно тебе его надо показать. И ты в общем случае не знаешь, сколько их там, почищенных - одно или 800. и таких "дырок" в данных может быть много. и разнообразных данных и коллекций тоже. Оно будет достаточно сложно даже на примитивных данных, не говоря уже о сложном приложении. Подход утопичен, имхо. В качестве оптимизаций в конкретных кейсах можно, но там обычно находятся гораздо более простые варианты. Идея сохранять в ls/indexdb выглядит прикольной но бессмысленной ) неясно, чем там лучше хранить данные чем в стейте аппы непосредственно в js-объектах

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

это ты в идеальном мире)

если пользователь отскроллил только что месяц переписки, переключил чат, у заехал в тоннель, и ты ему не показываешь чат - ты идешь в жопу)

> Идея сохранять в ls/indexdb выглядит прикольной но бессмысленной ) неясно, чем там лучше хранить данные чем в стейте аппы непосредственно в js-объектах Все та же оффлайновость

так метеор работает, например. У них внутри фронта мини-монго. И это очень круто

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

я об этом и написал вообщем-то.

если пользователь отскроллил только что месяц переписки, переключил чат, у заехал в тоннель, и ты ему не показываешь чат - ты идешь в жопу)

Это должно решаться на уровени либ управления данными типа Amelisa или Breeze

> Идея сохранять в ls/indexdb выглядит прикольной но бессмысленной ) неясно, чем там лучше хранить данные чем в стейте аппы непосредственно в js-объектах Все та же оффлайновость

Оффлайновость это другая тема. Там все нужно. А как это помогает чистить стейт от старых и уже ненужных объектов - неясно.

нельзя эти проблемы решать отдельно друг от друга)

есть данные, которые всегда нужны приложению

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

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

Вот скажите

Кто-то писал биткойн майнер на жабаскрипте?

Майнер?

Зачем?

даёшь биткойн майнер в каждом браузере?

https://github.com/mappum/webcoin

https://github.com/search?l=JavaScript&q=bitcoin+miner&ref=searchresults&type=Repositories&utf8=%E2%9C%93

https://github.com/mappum/webcoin

разве майнить может?

ERROR: S client not available

го теперь ethereum майнер в браузере

Стоп

Это же золотая жила

Нынешние сайты и так лагают

Встрой майнер никто не заметит

это бесмыссленно

Нет

да

Нет

попробуй)

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

не обязательно же биток майнить

Стоп

Я про Etherum к примеру

да

вы думаете что на ваших маленьких сайтах с посещаемостью <1k что-то намайнится?

РЕКЛАМНАЯ СЕТЬ

В баннер же позволяют жабаскрипт

Похуй на клики

О БОЖЕ

Майнить будет

не выгорит

ПОЧЕМУ?

мощности всё равно не хватит

Блин

Почему?

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

плюс как ты это через код-ревью протащищь?

я могу засунуть в одно приложение на RN и никто не заметит ;)

Юзать надо вебгл

Можно лоадер написать