ну ты говоришь вещи которые противоречат действительности

ты то.. ты сё

Еще, к примеру, за один элемент над другим может отвечать elevation если вы не знали.

про elevation не знал

ну ты говоришь вещи которые противоречат действительности

Я ?

Я ?

нет

александр

окей, elevation - Android only

про elevation не знал

Я не спец. Но проблем с zIndex не было. Может у вас в чем то другом была проблема?

окей, elevation - Android only

Если вы банально выставите zIndexЫ и один элемент загоните чуть под другой, то так и будет.

ладно, не будем уходить в сторону

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

вот такая структура

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

Я не встречал свичНавигатора.

Доступ всегда ко всему есть.

свичнавигатор в новой версии есть

окей

давайте конструктив

то же что и стек только табы не дублируются

свичнавигатор в новой версии есть

Офигеть я проспал. Надо будет почитать.

давайте конструктив

Там так же есть 1 хедер, который можно менять, или как? Секунду. Гляну его.

давайте конструктив

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

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

Можно в принципе сделать, чтобы это был невысокий Toast, который на пару секу будет сдвигать экран вниз через анимацию, а потом значение заново будет переводиться на null. Сейчас попробую кастомный Error Header ваш сделать.

Это над хедером и контент смещается. Но я понял куда копать - в кастомные хедеры

Что очень бы не хотелось(

В React Native бывают полностью рабочие навигаторы? wix, flux, rn... Печаль и беда.

React-navigation же рабочий

Он на JS вроде бы сделан, не совсем натив... А он умеет из одного стека в другой на указанный скрин переключаться?

Это над хедером и контент смещается. Но я понял куда копать - в кастомные хедеры

Братан, ну я в курсе, сам же писал. Это я к тому, что вы любой можете сделать, что позволяет фантазия. Не буду же я кучу вариантов сюда набрасывать )))

Это над хедером и контент смещается. Но я понял куда копать - в кастомные хедеры

Ничего плохого и сложного в кастомном хедере нет. Вы его сами напишите и сами будете легко понимать что там происходит. Тем более, он у вас всего 1 будет на все приложение, на сколько я понял.

Он на JS вроде бы сделан, не совсем натив... А он умеет из одного стека в другой на указанный скрин переключаться?

Может

Ну иконки туда пихать

Фунции разные в разных частях приложения

Он на JS вроде бы сделан, не совсем натив... А он умеет из одного стека в другой на указанный скрин переключаться?

Конечно. Это же только свойства навигации.

Конечно. Это же только свойства навигации.

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

Я первой пока пользуюсь, так как про вторую недавно только узнал. Косяки есть, но решаемо всё. Вы на досуге попробуйте быстро пару раз пальцем нажать на this.props.navigation.navigate(routeName).

Я первой пока пользуюсь, так как про вторую недавно только узнал. Косяки есть, но решаемо всё. Вы на досуге попробуйте быстро пару раз пальцем нажать на this.props.navigation.navigate(routeName).

Я через Redux сразу буду делать :-)

А двойное нажатие у меня сейчас и с wix'ом шалит

Если самое простое решение, то просто залочить последующие нажатия после первого нажатия, до получения ответа от первого. async / await, но я незнаю насколько это юзабельно.

На данный момент через state лочу последующие нажатия.

Всем добрый вечер, пытаюсь переходить на rn с реакта, кто-то юзает на рн-е recompose ?

Или же здесь лучше на классах ?

Да как хочешь)

А двойное нажатие у меня сейчас и с wix'ом шалит

Мы для wix навигатора сделали обёртку над push и showModal, которая блочит последующие переходы. При этом завязаться пришлось на ScreenVisibilityListener, потому что эвенты самого навигатора в каких-то кейсах не срабатывали

Ну и надо иметь в виду, там при showModal по два события прилетает в screen listener, одно с типом showModal, другое push

Если самое простое решение, то просто залочить последующие нажатия после первого нажатия, до получения ответа от первого. async / await, но я незнаю насколько это юзабельно.

А у wix навигатора в первой версии грустный интерфейс без промисов(

Мы для wix навигатора сделали обёртку над push и showModal, которая блочит последующие переходы. При этом завязаться пришлось на ScreenVisibilityListener, потому что эвенты самого навигатора в каких-то кейсах не срабатывали

Где-то встречал рекомендацию, не юзать модалки викса, а юзать модалки из натива. Кстати, насчёт визибилити листенера может оказаться полезной статья: https://medium.com/@ericacooksey/simplifying-react-native-navigation-with-a-redux-wrapper-8d5d530af8fc (в основном она про привзяку викса к редаксу). Внизу в каментах ссылка на "решение" проблемы с кнопками "Back" через экшны.

Где-то встречал рекомендацию, не юзать модалки викса, а юзать модалки из натива. Кстати, насчёт визибилити листенера может оказаться полезной статья: https://medium.com/@ericacooksey/simplifying-react-native-navigation-with-a-redux-wrapper-8d5d530af8fc (в основном она про привзяку викса к редаксу). Внизу в каментах ссылка на "решение" проблемы с кнопками "Back" через экшны.

Если вдруг попадется на глаза рекомендация - буду рад прочитать тоже) За статью спасибо, щас посмотрю

Поделитесь пожалуйста опытом, насколько оправдано использование React Native в српвнении с native приложениями? Много ли непреодолимых трудностей у реакта?

порог входа высокий?

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

Это над хедером и контент смещается. Но я понял куда копать - в кастомные хедеры

лол, зачем здесь кастномный хедер

лол, зачем здесь кастномный хедер

поделись опытом

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

или можно без обертки

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

бляха, советчиков развелось

ERROR: S client not available

вопрос был в том, чтобы этот Toast заезжал под хедер

как в инстаграме

и чтоооо

я показывал пример. статичный правда

и тооооо

в вебе ты бы это как делал?

на разных слоях, блок с абсолютом, который выезжает-заезжает из-под - под хедер

на разных слоях, блок с абсолютом, который выезжает-заезжает из-под - под хедер

что мешает сделать то же самое?

?

на разных слоях, блок с абсолютом, который выезжает-заезжает из-под - под хедер

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

https://stackoverflow.com/questions/30269014/react-native-unwanted-black-border-on-ipad-2-simulation

вопрос был в том, чтобы этот Toast заезжал под хедер

В чем проблема завернуть этот блок в контейнер с основным контентом с overflow:hidden и уползать его на top:-высота?

https://stackoverflow.com/questions/30269014/react-native-unwanted-black-border-on-ipad-2-simulation

немного не то. там речь походу о сплэше. а тут весь лэйаут с рамкой

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

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

А смысл? Нативную часть для иос и андроида отдельно писать придется - все бонусы рн пропадают а гемор добавляется

А так любую либу с нативной частью бери и смотри как сделано.

можно и я считаю это основной плюс рн, но соответственно и порог вхождения выше про сложность - не в ней даже дело. Нужна нативная задача - будьте готовы с ней пострадать - шаринг, карты, звук тот же, nfc. Часто необходимых реализаций просто не будет. Значит надо писать нативно самому. Без необходимых навыков вместо написания 1.5 приложений (что рн не кросплатформа становится понятно довольно скоро) затратите времени больше чем на 2 нативных p.s: не говорю про экспо, там вроде с нативом мучений нет. Но нет и основной фишки реакт натива

и я не нативщик если что

И считаю рн хорошим инструментом, но надо видеть границы (если заказчик хочет сэкономить получит соответствующий результат). Нативное приложение всегда гораздо более приятно выглядит

И считаю рн хорошим инструментом, но надо видеть границы (если заказчик хочет сэкономить получит соответствующий результат). Нативное приложение всегда гораздо более приятно выглядит

это все здорово. но знать 2-3 языка… к чему тогда нужно знать js + реакт нэтив, если таки знаешь нативные? когда можно избежать всего гемора связанного с кривыми, устаревшими или конфликтующими плагинами

ну я к тому и клоню

Ну и все таки нативная разработка гораздо дороже и не всем нужна (заказчикам)

Ну и все таки нативная разработка гораздо дороже и не всем нужна (заказчикам)

вот в оставшейся нише и трудятся реактивщики, ионщики и прочие кордовщики

дешево и сердито

это все здорово. но знать 2-3 языка… к чему тогда нужно знать js + реакт нэтив, если таки знаешь нативные? когда можно избежать всего гемора связанного с кривыми, устаревшими или конфликтующими плагинами

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

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

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

допустим есть три программиста - один ios, один android, один рн.. это нормальный подход если несложные интерфейсные элементы будет писать рн-программист, а что-то посложнее нативные программисты?

а зачем?

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

я имею в виду на ios+android два программиста будут работать столько же, сколько один на рн или дольше?

а зачем?

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