Но придется

Отмена запросов это конечно спорная вещь, но в общем случая не лишняя

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

не лишняя настолько, что надо делать свой велосипед?

https://www.npmjs.com/package/react-native-cancelable-fetch

последний коммит - в августе:)

не понятно, почему react-native в названии

и правда

уважаемые знатоки reactnavigation и redux, как мне проще брать params из навигатора в функции mapStateToProps в @connect

апну

чтож все так хотят отменять запросы то

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

а таймаут в фетче настраивается?

нет

Как в React Native можно работать с 3d позиционированием и изменять расстояние элементов "от экрана"? Нет никаких translateZ, а perspective влияет только на то, как выглядят изменения, не изменяя расположение элементов. Т.е. если два блока повернуть на разные углы, то они будут пересекаться и перекрывать друг друга.

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

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

Как в React Native можно работать с 3d позиционированием и изменять расстояние элементов "от экрана"? Нет никаких translateZ, а perspective влияет только на то, как выглядят изменения, не изменяя расположение элементов. Т.е. если два блока повернуть на разные углы, то они будут пересекаться и перекрывать друг друга.

порядком компонентов в рендере, или zIndex

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

ставь соединения в очередь, не обрабатывай повторяющиеся, игнорируй устаревшие

порядком компонентов в рендере, или zIndex

порядок ничего не дает, они все находятся на одном и том же z уровне

мне вот реально интересно, что кто собирается отменять в fetch

ну типа запрос ушел в dns

потом че

в какой момент отменять то кто что хочет

в какой момент отменять то кто что хочет

Мб скачку

в какой момент отменять то кто что хочет

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

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

Мб скачку

ну расскажите плиз как это работает) может есть ссыль на http спеку где такое есть?

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

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

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

не правда, у тебя ошибку кинут если пропало соединение

и никто в очередь не ставит

они все идут

не правда, у тебя ошибку кинут если пропало соединение

ок, очень слабая сеть

нет никакой очереди

одновременно не будет идти больше нескольких запросов, если там не какой-то другой мир.

одновременно не будет идти больше нескольких запросов, если там не какой-то другой мир.

почему бы им не идти одновременно?

в браузере, да, есть ограничение

почему бы им не идти одновременно?

http://stackoverflow.com/questions/39580193/why-do-browsers-limit-parallel-http-requests но это про браузеры зато очень известная инфа

в браузере, да, есть ограничение

а почему их нет в аппах?

ну так это браузер, мы сейчас не про него

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

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

да) но пока что это слова и домыслы с обоих сторон) и если количество соединений и правда ограничено, то это может быть ответом на вопрос, зачем нужен отменяемый fetch? :)

на отмену еще и два запроса уйдет http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm

причем это коннекшн а не запрос

в общем, в моей модели мира это всё сделано для разгрузки именно сетевых интерфейсов :) нужны еще мнения, а я ищу про concurrent connections

в общем, в моей модели мира это всё сделано для разгрузки именно сетевых интерфейсов :) нужны еще мнения, а я ищу про concurrent connections

что за разгрузка сетевых интерфейсов ?

что за разгрузка сетевых интерфейсов ?

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

ну щас посмотрим реализацию

в http нет отмены

просто разрывается соединение

просто разрывается соединение

вот интересно как оно разрывается)

начинается все тут кмк https://github.com/facebook/react-native/blob/master/Libraries/Network/XMLHttpRequest.js

Ну просто закрывается сокет, как обычно

Ну просто закрывается сокет, как обычно

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

Ну может быть в случае обычного дебаунса и быстрых запросов правильнее этого не делать

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

так тут получается выйгрыш то только в том что не будет парсится http response и все. причем я уверен что это делается мега быстро

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

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

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

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

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

какая разница когда он придет, сокет это все равно файл, он в памяти по сути не висит

Он висит в памяти

И помимо всего прочего есть ограничение на количество открытых файловых дескрипторов

Не знаю, какое оно на мобильных платформах

Он висит в памяти

это ты где такое прочитал)

Что сокет висит в памяти? А какие собственно варианты?

Что сокет висит в памяти? А какие собственно варианты?

сокет это файл, причем тут память собственно

Файл это довольно абстрактное понятие

И сокет это даже не файл в широком смысле

Все что связано с сокетом висит в памяти

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

Надо узнать ограничение на максимальное количество файловых дескрипторов

Если оно достаточно мало, то это вполне может играть роль в автокомплите и подобных вещах

Судя по всем NSURLConnection еще накладывает свои ограничения на количество одновременных запросов

пока что это всего лишь догадки)

Да проверить то несложно

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

Не должен, это достаточно неэффективно

Особенно когда https

ну вот и я о том же ?

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

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

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

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

На симуляторе 4 запроса максимум

на девайсе тоже

https://www.youtube.com/watch?v=s-G_RZ4RJLU

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

пробовал и визаутфидбэк и TouchableOpacity вобщем беда(

https://www.youtube.com/watch?v=s-G_RZ4RJLU

очень надеюсь что dot syntax это первоапрельская шутка

очень надеюсь что dot syntax это первоапрельская шутка

? так и есть )

Круто же, обфусцировать даже не придется

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

когда загоняю просто под рендер все ок

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

язык Java, библиотека usb4java

когда загоняю просто под рендер все ок

короче это было из-за прозрачной вьюшки с позицией абсолют которая перехватывала клики ???

короче это было из-за прозрачной вьюшки с позицией абсолют которая перехватывала клики ???

вот скатина

вот скатина

да я уже не первый раз напарываюсь(