Ребят, подскажите по логике, прочитал lifting-state-up, т.е. там просто поднимают состояние от ребёнка к родителю, а как передать состояние от одного родителя к другому?

зачем тебе поднимать состояние?

если нужно еще и шэрить его - то что не нужно поднимать

Мне его не нужно поднять, мне его нужно передать в другой

DanDanDan, привет, объясни поподробнее, плиз, что значит скриншотами?)

>Passing data between React components can be a little tricky at first (without using Redux that is), but once you practice these three techniques you’ll be able to pass data between whichever components you’d like. маленький трюк, найс)

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

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

@react_ru

Привет, для изучения react крайне желательно знать ES6, а поскольку ES6 это в большей степени улучшенный ES5, то js учить надо)

крайне желательно > обязательно

Ну есть по сути туториалы на ES5 для реакт, но крайне редко

крайне редко их можно встретить)

потому, что в них нет смыла?

мне что то кажется что что уже не желательно, а обязательно

через 3 месяца 2018 год

Ребят, подскажите по логике, прочитал lifting-state-up, т.е. там просто поднимают состояние от ребёнка к родителю, а как передать состояние от одного родителя к другому?

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

это и называется "lifting state up", типа вынос стейта на уровень вверх, чтобы с этого самого верхнего уровня можно было его передать твоим соседям

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

Получается так Parent -> child ^ —-> new child new child, создаётся без родителя как я понял

навигацией

Parent -> Child1, Child2, я правильно понимаю, что тебе из Child1 надо что-то передать в Child2?

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

как это? ?

его создаёт навигация как переход

как это - не имеет родителя? оО

у всех есть родители

хз, сам пытаюсь понять

что за сироты в реакте

?

this.props.navigation.navigate('child2')

вот так открывается второй из первого

навигейшн родитель обоих

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

А как слушать изменения?

в первом

если поменялся стейт навигации во втором

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

Вот и разбираюсь, но не фурычит)

если поменялся стейт навигации во втором

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

setParams - (helper) make changes to route's params

Ну как setState только для параметров, которые передаются

в роут

т.е. параметров текущего роута?

да

а если ты роутишь куда-то ещё, нельзя ли вторым параметром указать в том числе и новые параметры для нового роута?

а вот это я не понял

что у тебя за либа для навигации используется?

https://reactnavigation.org/docs/navigators/navigation-prop

из доков

ну вот, например: navigate - Link to other screens Call this to link to another screen in your app. Takes the following arguments: navigate(routeName, params, action) routeName - A destination routeName that has been registered somewhere in the app's router **params - Params to merge into the destination route**

Так всё передаётся вперёд хорошо, а как их назад то

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

писос)

это же основы

по мне так это логично

а почему вообще назад может быть с новыми параметрами?

тогда это не назад а назад в будущее с новым состоянием

тогда это не назад а назад в будущее с новым состоянием

+

представь todo list, при нажатий открывается новый экран с редактированием, по кнопке возвращаемся назад с новыми todos

представь todo list, при нажатий открывается новый экран с редактированием, по кнопке возвращаемся назад с новыми todos

просто не надо менять по кнопке назад, а сохранять надо в модели или сторе (редакс)

ну да, это ж явно не назад

ну да, это уже не параметры навигации, а отдельный стейт

это тебе грубо говоря надо прокидывать в нужный слайд какой-нибудь колбек addTodo, который этот слайд будет дёргать, и в котором уже будет добавление данных в какой-то отдельный "стор"

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

в случае с fetch, вроде нельзя

У меня Xhr

У меня Xhr

xhr.abort()

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

Зачем его отменять?

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

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

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

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

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

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

а, или база данных локальная, а не на серваке?

локальная

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

в любом случае будет просто игнорирование

если запрос отменен в тот момент, когда до сервера уже дошел запрос, ответ тоже проигнорируется

да даже если первый tcp пакет отправился то уже все

я вижу смысл отменять запрос, если ты загружаешь на сервер 10мб, но для обычных 1Кб запросов, я бы вообще не отменял

ушло и ушло, просто игноришь ответ и всё

я вижу смысл отменять запрос, если ты загружаешь на сервер 10мб, но для обычных 1Кб запросов, я бы вообще не отменял

или если твой запрос нагружает сервак

xhr.abort() просто закрывает TCP соединение и удаляет референс на xhr

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

он не отправляет на сервер команду "хей, серв, не выполняй запрос"

он не отправляет на сервер команду "хей, серв, не выполняй запрос"

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

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

хм, в принципе да

да и в тупую, сделать xhr.abort() проще, чем выставлять какие-то флаги, которые говорят "игнорируй ответы от xhr", особенно если тебе надо игнорировать не все ответы, а ответ от конкретного запроса =)

но я такого никогда не видел, честно говоря

может, опыта мало ¯\_(ツ)_/¯

не понял как это рвет соединение

ну xhr.abort убивает запрос

там в спеке есть

он просто tcp соккет же закрывает

как сервак то узнает что соединение закрыто

чем это отличается от закрытия соединения?

чем это отличается от закрытия соединения?

тем что сервер ничего про это же не знает