Там было что-то, что оптимизирует анимации внутри маркера, там же или в следующем коммите появился метод у маркера redraw

По нему можно поискать

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

Ишью о которой я упоминал про высокий загруз CPU на карте с кастомными маркерами на Android

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

Кто знает. Это как-то связано с тем, что натив хочет отличить тап от всяких других жестов, но плотно не копался - не в приоритете

По нему можно поискать

https://github.com/react-native-community/react-native-maps/commit/78a36ac3727d9781187b008d255fc365b7873f94

Ага

на коммите до него не было проблем

лучше бы я не смотрел в этот код... )

https://github.com/react-native-community/react-native-maps/commit/78a36ac3727d9781187b008d255fc365b7873f94

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

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

Вот это тот паттерн, где надо перепродумывать архитектуру, да

// Refresh according to docs _realMarker.tracksViewChanges = YES; _realMarker.tracksViewChanges = NO;

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

// Refresh according to docs _realMarker.tracksViewChanges = YES; _realMarker.tracksViewChanges = NO;

// Refresh according to docs _realMarker.tracksViewChanges = YES; _realMarker.tracksViewChanges = NO;

Меня больше вот это порадовало: // Let it render one more time to avoid race conditions. // i.e. Image onLoad -> // ViewChangesTracker may not get a chance to render -> // setState({ tracksViewChanges: false }) -> // image loaded but not rendered. updateMarkerIcon();

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

от знакомого слышал что в флаттере анимации неоч, лагают

Смотря как делать. Меня анимации как раз очень порадовали во флаттере

Но вот с IOS у них пока что беды

В плане перфоманса

На андроид прям гладенько работает

Но вот с IOS у них пока что беды

ну про иос и говорил))

Я оч надеюсь, что они это пофиксят с долгожданным переходом на Metal

На нем очень приятно писать

На андроид прям гладенько работает

Скролл дерганый

В релизе?

мне на свифте нравится писать

точнее под иос

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

В релизе?

Даже во flutter gallery их же

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

На IOS да, она есть, и оч грустная

Если просто скролить, то ок

Я понял о чем ты

Попробуй очень медленно начать

Я тоже таким баловался

Да

Мож в девайс прост упирается

Вроде где-то видел ишью про это

Может быть и такое, просто не в мою смену)

Зашла речь о флаттере и вспомнил об изолятах. Стало интересно, вдруг кто-нибудь намутил что-нибудь подобное для поточки в JS, и о боже: https://github.com/joltup/react-native-threads

Кто-то этим пользовался?

Если я создам приложение через Expo там будет ExoPlayer работать?

Если я создам приложение через Expo там будет ExoPlayer работать?

Надо пробовать, по идее он как-то в react-native-video зашит, а эта библиотека есть в Expo

Зашла речь о флаттере и вспомнил об изолятах. Стало интересно, вдруг кто-нибудь намутил что-нибудь подобное для поточки в JS, и о боже: https://github.com/joltup/react-native-threads

Имхо, это изначальное направление, которым надо было пойти, но отдельный модуль здесь ничего не изменит... надо было не выдумывать js, layout треды и по треду для модуля, а выполнять js в main thread в нем же делать лэйаут, вызовы в натив сделать синхронными без автоматического маршаллинга аргументов, но за то, позволить создавать воркеры стандартным апи для них, чтоб программисты могли выносить свои задачи из потока, где анимации ихэндлинг ввода происходит.

Имхо, это изначальное направление, которым надо было пойти, но отдельный модуль здесь ничего не изменит... надо было не выдумывать js, layout треды и по треду для модуля, а выполнять js в main thread в нем же делать лэйаут, вызовы в натив сделать синхронными без автоматического маршаллинга аргументов, но за то, позволить создавать воркеры стандартным апи для них, чтоб программисты могли выносить свои задачи из потока, где анимации ихэндлинг ввода происходит.

Звучит вполне здраво, но что им мешало/мешает сделать именно так?

Звучит вполне здраво, но что им мешало/мешает сделать именно так?

Без понятия, у меня только предположения и наблюдения... Но сейчас так сделать будет не очень просто - это будет другой продукт, это потребует написать DOM, и перестать выпендриваться с нативным react рендерером... И, о боже, это позволит выкинуть кучу кода )

А ещё это отрубит половину не очень продвинутых разработчиков, потому что придется думать при создании приложения (как для electron'а писать будет... т.е. часть работы в любом случае надо будет выносить в отдельный поток с которым rpc сооружать), и будет побочный эффект... куча народу этого делать не будет и у них всё будет тормозить, что плохо для имиджа )

А ещё это отрубит половину не очень продвинутых разработчиков, потому что придется думать при создании приложения (как для electron'а писать будет... т.е. часть работы в любом случае надо будет выносить в отдельный поток с которым rpc сооружать), и будет побочный эффект... куча народу этого делать не будет и у них всё будет тормозить, что плохо для имиджа )

И сейчас таких разработчиков полно

Что-то я понял, что так откладывать и буду это. Так что чуть менее может быть подробно, но основные пункты попробую изложить. История была такая, у меня не работал штатный Image, а когда работал делал это криво, особенно с флексибл компонентом. Я попробовал в нем разобраться и обнаружил там какой-то очень сложный пайплайн для картинок и в целом странный сложно понимаемый код. Плюс, когда картинка грузится из сети, её размеры становятся известны не сразу, и требуется релайаут, от которого фейсбук отказался, этот момент меня зацепил, хотелось понять так ли уж дорого это и так ли уж всё дергается, а если анимировать? Прикинул, что уже есть обкатанные решения для загрузки картинок из сети (выбрал SDWebImage для iOS и glide для Android, чуть не взял фреско для него, но им уже RN пользуется - не хотелось мешать зависимости) и сделал самую простую реализацию, которая делал то, что мне было надо в приложении, а именно - элемент изначально занимал какое-то пространство, картинка грузилась и размещалась в этом пространстве пропорционально занимая вертикаль или горизонталь полностью (т.е. режим "contain"). И у меня это отлично заработало. Это было в ноябре 2016. Дальше я добавил resizeMode (который поддерживали обе нативные библиотеки). Старался писать минимум кода, вся работа делегировалась нижележащим библиотекам. Дальше у меня это работало и я делал очень мало... подстраивался под новые версии RN ну и в январе 2017 сделал onError. (это последняя выпущенная в npm версия, я по прежнему работаю с этим компонентом, но прямо из github, пока меня это устраивает, тем более, что никто не напрягает, идею подхватил react-native-fast-image... и как бы пусть занимаются). Теперь, почему это сложно. 1. На самом деле это плохая архитектура. Нужно уметь кастомизировать размер кеша, управлять им, слать разные запросы (к примеру с авторизацией) в разных частях приложения. Т.е. правильный интерфейс, это - модуль, где можно регистрировать параметры сессий, где можно спросить есть ли картинка, где можно её предзагрузить или почистить кеш и отдельно компонент, при том не один. Потому что реально можно сделать компонент, который после понимания размеров, ресайзится с layout animation и это будет выглядеть хорошо и вполне подойдет галереям каким нибудь. Это много кодить и тут начнутся проблемы, что в нижележащих либах это управление сделано немного по разному (ну конкретно современный SDWebImage уже кажется умеет всё что нужно, но раньше не умел). 2. На самом деле требования к качеству картинок бывают очень разные - некоторым надо скорость и тогда картинку на диск надо класть так, чтоб её можно было загрузив (возможно через mmap спроецировав в память), сразу отправить в видюху. Некоторым надо показывать очень большие картинки (https://github.com/vovkasm/react-native-web-image/issues/18#issuecomment-354483466)... в общем нет одного универсального способа это хэндлить. 3. Из-за того, что я не ресайзил (как и фейсбук) элементы в самом начале, возникла одна очень интересная задача (я на ней много чего узнал и начал читать исходники браузеров). https://github.com/vovkasm/react-native-web-image/issues/2 Именно, т.к. картника занимала не весь элемент, а часть (resizeMode=contain), то код рисования бордюров не работал ожидаемым для пользователей способом. И я научился сам рисовать бордюры (на Android я это сделал почти до конца, на iOS уже поняв насколько это сложно, так и не довел до конца). Вообще код, который рисует правильно бордюры как в веб, очень сложный в браузерах, их сложно считать, сложно эффективно нарисовать, в мобилках в графических движках не хватает примитивов чтоб сделать это быстро. А в сочетании с картинками, это ещё включает доп проблемы: алиасинг, ну и либо картинку обрезать надо, либо маска, либо копировать картинку и рисовать бордюр сверху и уже это показывать, но при ресайзе получается опять это делать? В общем вот рисование бордюров, наверное самая сложная из всех технических проблем, с которой я столкнулся в процессе работы с этим модулем.

4. Вторая по сложности проблема (почему я не сделал автоопределение размеров) - не предусмотрено в yoga хуков, которые бы позволили сделать ререндер из натива в тот момент, когда элемент поймет свой размер. Вот нет этого функционала и всё. Только если через js делать (см. п.1).

OneSignal улетел в бан от роскомнадзора?

Уведомления перестали приходить. Кто-нибудь еще пользуется?

закрепленное сообщение

Уведомления перестали приходить. Кто-нибудь еще пользуется?

дак пуши прокидываются через firebase/apn

но onesignal да, чет не пашет

Там совершенно стандартный вью менеджер, так что да, размер вьюхи определяется из js посредством yoga.

Как такую фичу сделать?

collapseable toolbar. Статей полно

вариант "в лоб": скролл вью с верхним отступом, поверх абсолютный animated view c overflow: hidden, следишь за скроллом, меняешь прозрачность и высоту у animated

оптимизировать можно почти до бесконечности

reanimated-bottom-sheet или slideup-panel. Они дают animatable переменную, к которой можно привязывать прозрачность

Офигенно, спасибо)

Народ, словил такую штуку - например TouchableHighligh хайлайтит не сразу, а через 1/10 секунды где-то. Прочие компоненты тоже вроде как на глаз не мгновенно реаигруют ( без включенного remote JS debugging) Нужно каким-то способом максимально быстро получить отдачу. На Android был react-native-gesture-handlers с эффектом ripple, но что делать на iOS?

а на реальном устройстве с релиз-конфигурацией что?

Народ, словил такую штуку - например TouchableHighligh хайлайтит не сразу, а через 1/10 секунды где-то. Прочие компоненты тоже вроде как на глаз не мгновенно реаигруют ( без включенного remote JS debugging) Нужно каким-то способом максимально быстро получить отдачу. На Android был react-native-gesture-handlers с эффектом ripple, но что делать на iOS?

https://kmagiera.github.io/react-native-gesture-handler/docs/component-touchables.html

https://kmagiera.github.io/react-native-gesture-handler/docs/component-touchables.html

Все равно какая-то задержка 🙁

кстати, тачаблы из rn у меня отрабатывают мгновенно, а вот если взять из gesture handler, то задержка есть

Все равно какая-то задержка 🙁

проверь на реальном девайсе в релизной сборке

В slow-mo это выглядит вот так в проде. В Реале не так ужасно, но на придирчивый взгляд заметно

Gesture Handlers в production кстати лучше отрабатывают

В debug разница не так заметна

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

вчера писали что в флаттере скрол лагает на ios. Обидно. Хотя по всем параметрам лично для меня уже лучше звучит (чем рн)

К дарту сложно привыкнуть :(

Так, все проще

delayPressIn по умолчанию не 0

delayPressIn по умолчанию не 0

вот жеж срань

Осталось только понять почему при старте TouchableHighligh из rngh в активном состояниии до первого касания