а у меня может быть динамический контент), т.е. на точную высоту я не повешу)

Ребят можете посоветовать что нибудь на такой таск, у меня есть список и внизу него есть чатик, и у меня используется двойной скролл(нужно чтобы пока я не проскролил до конца внутренний скрол не включался), и как я решил эту задачу я проверяю у родительского компонента где все подключается достиг ли скролл конца, если да то делаю у родителя setState({isScrolling: true}), и в дочерний компонент(чат) передается в пропс nestedScrollEnabled={isScrolling} значение и наоборот. И мне кажется что это не хорошая реализация проверять на достижение высоты(и логически и когда я быстро скроллю вверх вниз между ними бывает баг что внутренний скролл куда то отскролливается думаю из-за setState). Может кому нибудь придет в голову как по другому это реализовать? Ответьте ссылкой пожалуйста на сообщение буду благодраен.

а есть подробная дока для чего он вообще?

Может кто знает где взять картинку для createDrawerNavigator https://prnt.sc/q72r4i там где логин выводится? Как подобную в google найти?

надо саму картинку, или просто способ как её туда поместить?

нечно подобное гуглится по запросу "material wallpaper"

https://i.stack.imgur.com/GGuG2.gif

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

или так: const WrapedOtherScreen = (props) => ( <View> <OtherNavigator {...props} /> <ActionButton /> </View> ) но пропсы все равно через redux придется в кнопку передавать

Всем привет. В RN (версия 0.59.9) при последовательном вызове нескольких нативынх Alert'ов в iOS они наслаиваются друг на друга. Я посмотрел, в файле RCTAlertManager.m есть метод -(void) invalidate, но я не вижу, чтобы он где-то ещё вызывался. Если добавить [self invalidate] внутрь дополнительного else if к if (!_alertControllers) {, то все предыдущие алерты будут закрыты и открыт только самый последний. В общем, выглядит как костыль, работает как костыль и т.д. Есть ли какие-нибудь другие варианты решения проблемы наслоения алертов в iOS? Форкать репо RN - не вариант. Остаётся, видимо, только создание кастомного нативного модуля Alert с этим костылём.

Всем привет. В RN (версия 0.59.9) при последовательном вызове нескольких нативынх Alert'ов в iOS они наслаиваются друг на друга. Я посмотрел, в файле RCTAlertManager.m есть метод -(void) invalidate, но я не вижу, чтобы он где-то ещё вызывался. Если добавить [self invalidate] внутрь дополнительного else if к if (!_alertControllers) {, то все предыдущие алерты будут закрыты и открыт только самый последний. В общем, выглядит как костыль, работает как костыль и т.д. Есть ли какие-нибудь другие варианты решения проблемы наслоения алертов в iOS? Форкать репо RN - не вариант. Остаётся, видимо, только создание кастомного нативного модуля Alert с этим костылём.

если изменения в одну строчку/файл то я делаю подобные вещи через postinstall

Ещё можно алерты в приложении менеджерить. У алертов есть коллбэк на закрытие (ну на нажатие кнопки фактически). И можно в своём менеджере трекать открытый текущий алерт и откладывать открытие следующего если уже открыто что-то, складывать в очередь и открывать после закрытия предидущего... как-то так...

Сначала хотелось обойтись малой кровью, но похоже не получится. Я думал в нативе предусмотрены такие вещи. Спрашивал нативщиков, кто под iOS пишет, но они вообще удивились этому кейсу, когда 20-30 алертов друг на друге. В андроиде, к счастью, старый dialog закрывается автоматически системой и только потом открывает новый. Про AppAlertQueue в js я тоже размышлял, но это целый сервис писать нужно вместо Alert.alert() :) Спасибо.

Сначала хотелось обойтись малой кровью, но похоже не получится. Я думал в нативе предусмотрены такие вещи. Спрашивал нативщиков, кто под iOS пишет, но они вообще удивились этому кейсу, когда 20-30 алертов друг на друге. В андроиде, к счастью, старый dialog закрывается автоматически системой и только потом открывает новый. Про AppAlertQueue в js я тоже размышлял, но это целый сервис писать нужно вместо Alert.alert() :) Спасибо.

Вообще эта ситуация может служить подсказкой, что это не совсем удачный вариант UI для решаемых проблем. Ведь алерт обычно подразумевает явное действие пользователя (да ещё с максимальным привлечением внимания) по закрытию, часто вариант выбора. И в этом контексте система не должна его закрывать, напротив, для пользователя все остальные процессы в приложении должны бы остановиться... Это не значит, что алерт нельзя прервать, это значит, что ситуация прерывания алерта должна рассматриваться как редкая и исключительная. Когда алерты не требуют решения от пользователя и не прерывают работу, это скорее оповещения, так их и надо через toast или snackbar или ещё каким не сильно мешающим работе способом показывать. Тем более когда их может быть 20-30 )

Так можно же взять Алерт jsовский из нпм пакета любого, и привязать его, если неохото самому писать

Согласен. Но это ещё подходящий нам нужно найти. Если бы было так легко и просто тяп-ляп, как в вебе :D

На самом деле там и есть явное ожидание действия от пользователя. И алерт по своей сути - дублирование пуш-уведомления. Предлагает открыть экран с *секретная бизнес-логика* или просто дизмиснуть алерт. И вот при одновроменном приходе нескольких пушей валится куча алертов. Если честно, я не знаю зачем это так сделано, но похоже придётся серьёзно поговорить с ПМом на эту тему :)

Я кажется понял кейс. Советую queue соорудить, да ещё такое, чтоб после закрытия предидущего проходила хотя бы секунда до следующего. А ещё советую обсудить возможность сделать это вот таким элементом в приложении (а не алертом): https://material.io/components/banners/banners.html#anatomy или аналогом

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

android pay без stripe’a не работает?

работает. Но у меня были проблемы с ревью гугловым с либой react-native-payments. В итоге неспеша в течение месяца парились в беседах с гуглом и возней с либой, а потом за вечер запилили модуль на java прям с оф доки и прошли ревью Вообще у нас пм хочет статью оформить по androidpay/applepay. Там на самом деле больше общения с банками чем программирования. С докой у банков беда

обычно делаем вебвью оплату. Бек дает ссылку на оплату. Договариваемся на redirect при успешной/нет оплате и перехватываем в прилке Но не знаю что для этого нужно в плане договоров androidpay я думаю для простой оплаты не особо нужен. Там же еще ревью от гугла проходить дважды - с enviroment.TEST и PRODUCTION

Как насчёт Braintree Payment?

Думал капает в итоге это всё на gPay баланс и выводишь на любую дебетовую карту)

ты про внутрение покупки?