и вот почему то при переходе вперед не работает анмаунт, а назад работает

Могу предположить (знатоки react-navigation меня могут поправить), что стек навигатор не заментяет скрины, а как бы накладывает один на другой, т.е. более старые компоненты в стеке остаются активными. Следствием этого будет в частности описываемое вами поведение.

Т.е. когда вы переходите назад, компонент с верхушки стека, действительно удаляется и из-под него становится виден предидущий экран, в итоге unmount у компонента вызвается. А когда происходит переход вперед, текущий компонент никуда не исчезает, просто его не видно за новым, естественно никакого анмаунта не происходит... просто маунтится и рендерится новый компонент, который становится текущим и анимируется так чтоб занять весь экран...

Могу предположить (знатоки react-navigation меня могут поправить), что стек навигатор не заментяет скрины, а как бы накладывает один на другой, т.е. более старые компоненты в стеке остаются активными. Следствием этого будет в частности описываемое вами поведение.

все так, подтверждаю)

там вроде даже в доке было это написано

Т.е. когда вы переходите назад, компонент с верхушки стека, действительно удаляется и из-под него становится виден предидущий экран, в итоге unmount у компонента вызвается. А когда происходит переход вперед, текущий компонент никуда не исчезает, просто его не видно за новым, естественно никакого анмаунта не происходит... просто маунтится и рендерится новый компонент, который становится текущим и анимируется так чтоб занять весь экран...

Спасибо большое, понял теперь, буду думать, как реализовать, потому что на didmount я вешаю специальный переход по роуту на физ кнопку андроид через BackHandler, и получается, вешать вешаю, а из за того, что unmount не срабатывает, хэндлер не сбрасывается и начинает работать там, где не должен быть

И кое какой роутинг нарушается

Могу предположить (знатоки react-navigation меня могут поправить), что стек навигатор не заментяет скрины, а как бы накладывает один на другой, т.е. более старые компоненты в стеке остаются активными. Следствием этого будет в частности описываемое вами поведение.

В новых версиях это пофиксили, теперь только через push остаются.

И они тоже spyware (так же, как react-native-firebase), из-за вот этого: https://github.com/aksonov/react-native-router-flux/blob/4.0.1/package.json#L14

Сори за нубский вопрос, но что этот код делает? Что они там отслеживают и как это отразится на моем приложении (уже юзаю react navigation и планирую подключить rnfirebase)

Сори за нубский вопрос, но что этот код делает? Что они там отслеживают и как это отразится на моем приложении (уже юзаю react navigation и планирую подключить rnfirebase)

Этот код при каждом npm install вызывает скрипт от opencollective, который ходит на их сервера по сети и забирает текущие цифры по бюджетам чтоб показать красивый баннер в терминале. Это официально. Что они там трекают и сохраняют из этих запросов на серверах своих, мы не знаем )

Oo... они ещё и прям то, что с сайта https://opencollective.com/... получили (текст логотипа), прям напрямую в терминал пуляют, без фильтрации ESC-последовательностей...

Но из позитива, у них в коде появились ручки, чтоб это вырубать на всяких CI и production серверах

В новых версиях это пофиксили, теперь только через push остаются.

То есть обновиться поможет решить проблему?

То есть обновиться поможет решить проблему?

если у вас react-navigation то да, теперь экраны умирают, если с них уходишь.

если у вас react-navigation то да, теперь экраны умирают, если с них уходишь.

react-native-router-flux у нас стоит на проекте

react-native-router-flux у нас стоит на проекте

аа.. ну тогда не знаю, этой штукой пользовался один раз и то давно. Просто там писали про react-navigation

аа.. ну тогда не знаю, этой штукой пользовался один раз и то давно. Просто там писали про react-navigation

Эх, беда с этой либой какая то)

если у вас react-navigation то да, теперь экраны умирают, если с них уходишь.

Это не поможет, в данном случае... т.к. их умирание в общем случае не связано с навигацией... потому что экран должен остаться по крайней мере, пока его видно из-под нового... т.е. до конца транзишна... А если навигация свайпом включена (не знаю есть она в react-navigation или нет... в NavigationExperimental была...), то по крайней мере тот экран, что под верхушкой стека должен жить всё время)

Это не поможет, в данном случае... т.к. их умирание в общем случае не связано с навигацией... потому что экран должен остаться по крайней мере, пока его видно из-под нового... т.е. до конца транзишна... А если навигация свайпом включена (не знаю есть она в react-navigation или нет... в NavigationExperimental была...), то по крайней мере тот экран, что под верхушкой стека должен жить всё время)

Есть свайп, так то да.

Эх, беда с этой либой какая то)

https://medium.com/@Laurens_Lang/react-native-migrating-from-react-native-router-flux-to-react-navigation-7c47b1cc679c

На самом деле если я правильно понимаю, что нужно @zharkov_r , то это надо делать вообще не в UI слое... и уж тем более не привязываться к life-cycle реакт компонентов. Это должно быть в модели навигации... именно там, где происходит переключение скринов и запуск транзишнов.

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

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

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

Кто-нить подскажите

почему вот тут: https://github.com/keri4141/React-Native-Navigation-Redux-Example

на экране hometab, нельзя обратиться к хранилищу через this.props

и достать то что в initialState

ошибка вылазит undefined

на экране hometab, нельзя обратиться к хранилищу через this.props

Для этого к нему нужно сначала подключиться через connect и пробросить пропсы

const mapStateToProps = state => ({ users: state.users }); export default connect(mapStateToProps)(Hometab);

все подключено

Dmitry

А вызывается как

И да, в registerComponent прокинут store и Provider ?

Navigation.registerComponent( "ReactNativeReduxExample.Hometab", () => Hometab, store, Provider );

const createStoreWithMiddleware = applyMiddleware(thunk)(createStore); const reducer = combineReducers(reducers); const store = createStoreWithMiddleware(reducer);

вызываю консоль логом

и вижу пропс проброшен

но значение undefined

хотя вот

const initialState = Immutable({ root: undefined, users: "user123", isLoading: false });

а, надо было в mapState не state.prop а state.root.prop обращаться

вопрос закрыт

Привет всем! А есть ли тут люди, которые делали приложения с реферальной системой? Чтобы можно было привлекать друзей в приложение и получать за это бонусные баллые?

А вот вам задачка, хорошего решения я пока не нашел, поэтому довольствуюсь плохим, но более менее рабочим. Итак, есть некий REST API, который возвращает массив сообщений. Запрашиваем, получаем, кладем в стор и работаем с ними. Как результат имеем всегда свежие данные. Далее, я хочу сделать возможность оффлайн просмотра последних N сообщение и кладу их в AsyncStorage. Перед запросом на сервер кидаю в стор данные из AsyncStorage, а свежие данные докидываю, когда прилетят. Пока все просто и понятно. Далее, сообщения могут быть изменены на сервере и тогда в запросе прилетят обновленные сообщения, тут мы просто их мерджим. А далее самое сложное (на мой взгляд), сообщения могут быть удалены на сервере, тогда в запросе их не будет и нужно, а они лежат в AsyncStorage. Сейчас в запросе прилетают все сообщения с флагами deleted и по нему удаляются из AsyncStorage, но тогда приложения всегда тянет лишние данные, которых может быть очень много. Для решения был сделан polling для отправки события удаления сообщения на сервере к приложению и по нему эти сообщения удаляются из AsyncStorage и тут возникает новая проблема. У одного получателя может быть несколько устройств с приложениями и своми кэшами, которые могут быть оффлайн на момент получения уведомления от сервера. Можно было помечать доставленные уведомления от сервера к конкретному приложению, но текущая реализация нигде не хранит уведомления, они создаются в момент, какого-то события, отправляются один раз и, в случае не получения уведомления (оффлайн), получатель второй раз его уже не получит. Может быть, кто-то сталкивался с такими задачи на правктике или имеет свои мысли на этот счет, с удовольствием обсужу варианты)

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

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

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

А как выглядит метод запроса удаленных, какие параметры?

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

А как выглядит метод запроса удаленных, какие параметры?

Принудительно удаленные не запрашиваются

Они пушатся?

Они пушатся?

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

Возможно, стоит получать «историю» изменения сообщений, легковесный запрос, не привязанный к конкретному устройству, там лишь нужен некий id для получения истории (дата, номер последнего и т.п)

В EWS, Gmail всё примерно так, в IMAP чуть упрощённее. Но это почта. В мессенджерах повеселее протоколы, наверное, можно их курить.

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

Возможно, стоит получать «историю» изменения сообщений, легковесный запрос, не привязанный к конкретному устройству, там лишь нужен некий id для получения истории (дата, номер последнего и т.п)

Ну мы сейчас и говорим о мессенджере, самое интересное они на показ не выставляет)

У телеграмма открыт код вроде как

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

В онлайне так и есть, но ни iOS ни Android не гарантируют достувку пушей, плюс ты можешь его смахнуть и приложение о нем не узнает

в андроиде можно получить и обработать, даже не показав вот в ios не уверен, но помоему там на 30 сек запускается апп при voip пуше. а если сделать фоновую процесс (через то что в RN есть) и ходить на сервер раз в час или как система пустит, за списком удаленных. в запрос добавить время с которого надо начинать список

В iOS есть silent push

ERROR: S client not available

в андроиде можно получить и обработать, даже не показав вот в ios не уверен, но помоему там на 30 сек запускается апп при voip пуше. а если сделать фоновую процесс (через то что в RN есть) и ходить на сервер раз в час или как система пустит, за списком удаленных. в запрос добавить время с которого надо начинать список

в принципе можно попробовать

А вот вам задачка, хорошего решения я пока не нашел, поэтому довольствуюсь плохим, но более менее рабочим. Итак, есть некий REST API, который возвращает массив сообщений. Запрашиваем, получаем, кладем в стор и работаем с ними. Как результат имеем всегда свежие данные. Далее, я хочу сделать возможность оффлайн просмотра последних N сообщение и кладу их в AsyncStorage. Перед запросом на сервер кидаю в стор данные из AsyncStorage, а свежие данные докидываю, когда прилетят. Пока все просто и понятно. Далее, сообщения могут быть изменены на сервере и тогда в запросе прилетят обновленные сообщения, тут мы просто их мерджим. А далее самое сложное (на мой взгляд), сообщения могут быть удалены на сервере, тогда в запросе их не будет и нужно, а они лежат в AsyncStorage. Сейчас в запросе прилетают все сообщения с флагами deleted и по нему удаляются из AsyncStorage, но тогда приложения всегда тянет лишние данные, которых может быть очень много. Для решения был сделан polling для отправки события удаления сообщения на сервере к приложению и по нему эти сообщения удаляются из AsyncStorage и тут возникает новая проблема. У одного получателя может быть несколько устройств с приложениями и своми кэшами, которые могут быть оффлайн на момент получения уведомления от сервера. Можно было помечать доставленные уведомления от сервера к конкретному приложению, но текущая реализация нигде не хранит уведомления, они создаются в момент, какого-то события, отправляются один раз и, в случае не получения уведомления (оффлайн), получатель второй раз его уже не получит. Может быть, кто-то сталкивался с такими задачи на правктике или имеет свои мысли на этот счет, с удовольствием обсужу варианты)

web sockets, подписки в graphQL? Вы описываете real-time приложение, идеальная реализация которого graphQL + Apollo.

А вот вам задачка, хорошего решения я пока не нашел, поэтому довольствуюсь плохим, но более менее рабочим. Итак, есть некий REST API, который возвращает массив сообщений. Запрашиваем, получаем, кладем в стор и работаем с ними. Как результат имеем всегда свежие данные. Далее, я хочу сделать возможность оффлайн просмотра последних N сообщение и кладу их в AsyncStorage. Перед запросом на сервер кидаю в стор данные из AsyncStorage, а свежие данные докидываю, когда прилетят. Пока все просто и понятно. Далее, сообщения могут быть изменены на сервере и тогда в запросе прилетят обновленные сообщения, тут мы просто их мерджим. А далее самое сложное (на мой взгляд), сообщения могут быть удалены на сервере, тогда в запросе их не будет и нужно, а они лежат в AsyncStorage. Сейчас в запросе прилетают все сообщения с флагами deleted и по нему удаляются из AsyncStorage, но тогда приложения всегда тянет лишние данные, которых может быть очень много. Для решения был сделан polling для отправки события удаления сообщения на сервере к приложению и по нему эти сообщения удаляются из AsyncStorage и тут возникает новая проблема. У одного получателя может быть несколько устройств с приложениями и своми кэшами, которые могут быть оффлайн на момент получения уведомления от сервера. Можно было помечать доставленные уведомления от сервера к конкретному приложению, но текущая реализация нигде не хранит уведомления, они создаются в момент, какого-то события, отправляются один раз и, в случае не получения уведомления (оффлайн), получатель второй раз его уже не получит. Может быть, кто-то сталкивался с такими задачи на правктике или имеет свои мысли на этот счет, с удовольствием обсужу варианты)

При такой постановке - REST API... хорошего (прям реал-тайм) решения не будет. Нужна возможность пуша со стороны сервера (не мобильного, а просто послать клиенту что-то без поллинга)... Вот вам кратко мой вариант: 0. Для простоты - "канал сообщений" (список) один глобальный, все клиенты равноправны. Мы оптимизируем время обновления и трафик. Мы не оптимизируем время разработки и не подстраиваимся под существующие решения. 1. Транспорт WebSockets, енкодинг произвольный, допустим json. 2. Сообщение на сервере, помимо прочего имеет атрибуты: id, таймштамп создания, таймштамп изменения, флаг "удалено". 3. После загрузки и установки соединения, клиент делает запрос: "сервер, дай мне список последних N сообщений, у меня есть сообщения с ID1 по ID2, последний раз я получал их во время T", сервер на это шлет a. если диапазон последних N сообщений не пересекается с ID1-ID2, то список с флагом, что кеш надо почистить. b. если диапазон пересекается, то: список новых сообщений, список обновившихся с момента T из диапазона ID1-ID2 сообщений, в том числе удаленных (для экономии трафика, можно слать удаленные отдельным списком айдишников) Т.е. ответ сервера, это: список изменившихся сообщений и флаг сброса кеша 4. С момента соединения, сервер так же абсолютно независимо от п.3 до момента дисконнекта шлет отдельными командами обновления на каждое новое, модифицированное или удаленное сообщение всем приконнекченным клиентам... 5. Клиент, получив ответ на 3, мержит к себе в модель данных изменения, при необходимости стирает кеш (м.б. клиент последний раз год назад открывали) и разблокирует UI (в том смысле, что показать кеш можно было и раньше, но давать менять что-то не надо бы). 6. Клиент с самого начала слушает индивидуальные обновления от сервера, по каждому соотвественно обновляет модель.

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

При такой постановке - REST API... хорошего (прям реал-тайм) решения не будет. Нужна возможность пуша со стороны сервера (не мобильного, а просто послать клиенту что-то без поллинга)... Вот вам кратко мой вариант: 0. Для простоты - "канал сообщений" (список) один глобальный, все клиенты равноправны. Мы оптимизируем время обновления и трафик. Мы не оптимизируем время разработки и не подстраиваимся под существующие решения. 1. Транспорт WebSockets, енкодинг произвольный, допустим json. 2. Сообщение на сервере, помимо прочего имеет атрибуты: id, таймштамп создания, таймштамп изменения, флаг "удалено". 3. После загрузки и установки соединения, клиент делает запрос: "сервер, дай мне список последних N сообщений, у меня есть сообщения с ID1 по ID2, последний раз я получал их во время T", сервер на это шлет a. если диапазон последних N сообщений не пересекается с ID1-ID2, то список с флагом, что кеш надо почистить. b. если диапазон пересекается, то: список новых сообщений, список обновившихся с момента T из диапазона ID1-ID2 сообщений, в том числе удаленных (для экономии трафика, можно слать удаленные отдельным списком айдишников) Т.е. ответ сервера, это: список изменившихся сообщений и флаг сброса кеша 4. С момента соединения, сервер так же абсолютно независимо от п.3 до момента дисконнекта шлет отдельными командами обновления на каждое новое, модифицированное или удаленное сообщение всем приконнекченным клиентам... 5. Клиент, получив ответ на 3, мержит к себе в модель данных изменения, при необходимости стирает кеш (м.б. клиент последний раз год назад открывали) и разблокирует UI (в том смысле, что показать кеш можно было и раньше, но давать менять что-то не надо бы). 6. Клиент с самого начала слушает индивидуальные обновления от сервера, по каждому соотвественно обновляет модель.

Как гарантировать целостность, если например с ID1 по IDn есть пропущенные сообщения. По ним не получить актуальную информацию

Как гарантировать целостность, если например с ID1 по IDn есть пропущенные сообщения. По ним не получить актуальную информацию

В смысле? Сервер вам их вернет как новые, если такое вдруг случилось...

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

На самом деле...

Пока я расписывал всю эту историю, похоже что пришёл к решению

Достаточно хранить историю событий, которые произошли в оффлайне и отдавать ее при входе в онлайн

Рассказываю рассказываю уже сам понял а они...

Рассказываю рассказываю уже сам понял а они...

Где-то читал - «Мой кот прекрасно разбирается в программировании. Стоит рассказать ему проблему, как тут же находится решение.»

Ну это "желтая уточка")

https://ru.wikipedia.org/wiki/Метод_утёнка

Ну это "желтая уточка")

Да)

Работает кстати))

Факт

А кто нибудь вообще пытался проксировать сокеты через NGINX? Я Билый час потратил так и не завелось

Спасибо, перепроверю, но по-моему у меня при схожем конфиге не завелось...

Была такая проблема , вам нужно открыть в студи не корень проекта , а <project_root>/android

Была такая проблема , вам нужно открыть в студи не корень проекта , а <project_root>/android

всмысле не корень проекта , а <project_root>/android? я сейчас просто собираюсь открыть эмулятор у меня нет никакого проекта сейчас по андроид студио. открываю я студию как обычно через в линуксе `<my_path>/android-studio/bin/studio.sh`

не понел что мне сделать

всмысле не корень проекта , а <project_root>/android? я сейчас просто собираюсь открыть эмулятор у меня нет никакого проекта сейчас по андроид студио. открываю я студию как обычно через в линуксе `<my_path>/android-studio/bin/studio.sh`

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

без запуска студии запускаю эмулятор в таком стиле: emulator -avd Pixel_API_27

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

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