Вообще, кто как считает - тс с рн норм или лучше просто джс?

тс

Вообще, кто как считает - тс с рн норм или лучше просто джс?

Рекомендую книгу "React Native in Action" 2019, по отзывам нормальная. Я сейчас по ней изучаю, вроде хорошая

Книга Fullstack React Native тоже вроде хорошая

Ссылка на книгу "React Native in Action" 2019 - http://www.allitebooks.org/react-native-in-action/

Всем привет, завтра буду отправлять на проверку первую версию приложения с auto-renewable подпиской. Валидацию receipt провожу на клиенте, соответственно devMode указываю там же. Вопрос: review team использует же sandbox аккаунты? Как поступить в данной ситуации, после успешного прохождения проверки с помощью OTA поменять девмод на продакшн? Или же можно отправлять версию с валидацией не для sandbox? Заранее спасибо за ответ 🙏

всем привет. Использую https://github.com/reactjs/react-tabs Не получаеться изменить стили... Пишу так же в своем файле scss, не меняються

всем привет. Использую https://github.com/reactjs/react-tabs Не получаеться изменить стили... Пишу так же в своем файле scss, не меняються

вы ошиблись чатом

вы ошиблись чатом

по самому реакту тут не подскажут?

нет, всё равно это оффтоп будет, ибо Ваш вопрос не касается рна

вы ошиблись чатом

Какая блин разница 🙃

из-за таких как вы и набирают реакторов в мобильщики

Какая блин разница 🙃

Большая)

из-за таких как вы и набирают реакторов в мобильщики

А разница одного фронта от другого прям велика?

имхо, достаточно велика, да и ваш вопрос из разряда "спрошу про Spring у андроид девелоперов, они же на Java пишут"

ой, это не ваш вопрос был, сорри, но всё же)

имхо, достаточно велика, да и ваш вопрос из разряда "спрошу про Spring у андроид девелоперов, они же на Java пишут"

Как правило они то знают. Но вопрос не в этом - РН основан на реакте, ни думаю что кто-то сразу изучает рн без знаний реакта

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

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

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

Всем привет. Пуши от файербейза можно проверить на симуляторе иос? или только на реальном девайсе?

Всем привет. Пуши от файербейза можно проверить на симуляторе иос? или только на реальном девайсе?

Должны, на экспо же приходят

Всем привет. Пуши от файербейза можно проверить на симуляторе иос? или только на реальном девайсе?

на симуляторе iOS не приходят уведомления, на реальном нужно проверять

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

ещё раз, знание реакт в рамках рна не обязывает знать работу всех либ для reactjs, как и знание Java для нативного Android не обязывает знать Spring

просто странно, что с симулятором андроид работают 🤔

просто странно, что с симулятором андроид работают 🤔

Это норма)

т.е. это фишка иос?

Потому что у андроида эмулятор

А не симулятор

в Андроиде полноценная эмуляция устройства, а у iOS симуляция работы оси

ааа, понял

спасибо

ещё раз, знание реакт в рамках рна не обязывает знать работу всех либ для reactjs, как и знание Java для нативного Android не обязывает знать Spring

что вы злые такие?

но я не злой =(

что вы злые такие?

просто нужно отделять мухи от котлет

просто нужно отделять мухи от котлет

ну извините. Я по-другому думал

Всем привет, завтра буду отправлять на проверку первую версию приложения с auto-renewable подпиской. Валидацию receipt провожу на клиенте, соответственно devMode указываю там же. Вопрос: review team использует же sandbox аккаунты? Как поступить в данной ситуации, после успешного прохождения проверки с помощью OTA поменять девмод на продакшн? Или же можно отправлять версию с валидацией не для sandbox? Заранее спасибо за ответ 🙏

А как бы ты поступил в случае с полностью нативным приложением? Там ОТА нет

Слушайте, это пока скорее праздный вопрос. Я поискал по истории и понял, что довольно многие использют react-native-gesture-handler (https://github.com/kmagiera/react-native-gesture-handler). Правильно? У меня возникло два вопроса. 1. А вы его используете частично или всё взаимодействие на него перевели? 2. А если всё взаимодействие через него, были ли "конфликты" или ещё что-то в сочетании с другими модулями с нативными вьюхами типа react-native-webview, react-native-maps и т.п.?

в модалке родной не работал, но модалку родную лучше вообще не юзать

Я так понял, что по авторизации/регистрации никто не поможет примером или туториалом?)

Я так понял, что по авторизации/регистрации никто не поможет примером или туториалом?)

Продублируй вопрос

Я спрашивал: есть ли пример или туториал по авторизации/регистрации? И какой стек использовать лучше rn+firebase+redux?

Я спрашивал: есть ли пример или туториал по авторизации/регистрации? И какой стек использовать лучше rn+firebase+redux?

Ответ будет типичный :) Все зависит от задачи. Хотите firebase - используйте, хотите - нет. Redux может выступать лишь прослойкой, которое хранит состояние во время активной работы приложения. Хоть mobx, хоть effector, хоть в rxjs храни состояние. Что касается маршрутизации, то в большинстве случаев подойдёт SwitchNavigator. Но у нас на своём проекте была отдельная нативная активити для регистрации/авторизации, которая могла вызываться с любого экрана.

В firebase как я понял можно отправлять бесплатно смс, как подтверждение регистрации, или я что-то путаю?

В firebase как я понял можно отправлять бесплатно смс, как подтверждение регистрации, или я что-то путаю?

100 юзеров ограничение, вроде, в бесплатном пакете. Или 100 смс в месяц. Точно не помню

ну платный 25$?

ну платный 25$?

Не скажу

Мы только cloud messaging использовали

Спасибо за ответ, пойду искать дальше)

А для роутов эту часто использут https://github.com/aksonov/react-native-router-flux

А для роутов эту часто использут https://github.com/aksonov/react-native-router-flux

Ну... обычно видел у тех, кому лень разбираться в навигации :)

А для роутов эту часто использут https://github.com/aksonov/react-native-router-flux

В чем прикол? Чем это лучше/хуже react-navigation? Последний, как по мне, с выходом react-navigation-screens приговорил конкурентов

* правда интересны +-, это не попытка поднять бучу)

В чем прикол? Чем это лучше/хуже react-navigation? Последний, как по мне, с выходом react-navigation-screens приговорил конкурентов

он скорее себя приговаривает)

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

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

ну он стал шустрее да, но все равно медленнее чем rnn

и, на мой взгляд, у rnn конфиги менее громоздкие и он проще в управлении

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

А проверь на iPhone 5s, а то вдруг это safe area?

такое же поведение. Я уже и поубирал все обертки. Единственное, что остается это обертка самого экрана в стэке

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

ну смотря как использовать

такое же поведение. Я уже и поубирал все обертки. Единственное, что остается это обертка самого экрана в стэке

чисто на всякий - костыль с таймаутом на отключение refreshing не работает?

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

чисто на всякий - костыль с таймаутом на отключение refreshing не работает?

а в момент когда он крутится итак refreshing = false

сейчас попробую конечно

я себе вот такой костыль написал import React from 'react'; import { RefreshControl, RefreshControlProps, Platform } from 'react-native'; interface Props extends RefreshControlProps { } interface State { showRealRefreshing: boolean; } export default class SafeRefreshControl extends React.Component<Props, State> { state: State = { showRealRefreshing: Platform.OS === 'ios', }; componentDidMount() { setTimeout(() => { this.setState({ showRealRefreshing: true }); }, 500); } render() { return ( <RefreshControl {...this.props} refreshing={this.state.showRealRefreshing && this.props.refreshing} /> ); } }

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

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

пришел к выводу что не стоит создавать RefreshControl с refreshing=true, поэтому сделал таймаут

пришел к выводу что не стоит создавать RefreshControl с refreshing=true, поэтому сделал таймаут

Ну так он изначально false. Потом срабатывает запрос на событие фокуса экрана из react-navigation, там выставляется в true, а в конце в false. Но последний уже игнорируется получается...

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

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

вот перед последней сменой на false тоже делаю задержку

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

ну тут не подскажу, такое поведение вообще противоречит логике =)

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

Тут все упирается в деревянность вашего дизайнера) Не все приложения пишутся в купертино/материал)

Где-то такие переходы нужны

Тут все упирается в деревянность вашего дизайнера) Не все приложения пишутся в купертино/материал)

не согласен. В iOS справа прилетает экран, который можно смахнуть назад. Снизу же прилетает экран, который modal и используется чаще всего для блокируемых экранов, которые закрываются по кнопке. Если такой экран вывести справа или слева или откуда то еще, как в андройде, то ломается логика UI натива =)

это уже дизайнеры дурачатся)

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

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

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

ну вот хак с таймаутом на false вроде сработал,. но выглядит стремно)

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

ну вот хак с таймаутом на false вроде сработал,. но выглядит стремно)

я еще заметил интересную штуку, что когда проставляется true RefreshControl не появляется, но его можно вытянуть сверху... Какой-то лютый баг, причем воспроизводится именно в контексте метода от react-navigation

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

поэтому я и написал, что импользование rnn зависит от задач, но я всегда отдаю ему предпочтение, потому что он намного проще в эксплуатации, чем react-navigation и быстрее. Если rnn не удовлетворяет задачам, то уже ничего не поделаешь

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