так фабрик же про это

Вообще у меня, пока я тут копаюсь, всё больше видение сдвигается в сторону того, что в Android нельзя делать через NDK это. Надо JS компилить в JVM вместе с движком, только так и тогда можно будет написать на JS прямой и быстрый вызов в Java.

почему нельзя?

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

SafeArea, подойдет? ) На самом деле любой лэйаут может этого хотеть... Свой Text компонент... к примеру супер быстрый Label

а как ты видишь решение? и почему обязательно на UI треде должно быть (в смысле не асинхронное)?

а как ты узнал (я правда если что не знаю), что в том же ios синхронно рассчитываются констрейнты?

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

Привет! Может, подскажите, видели ли подобное, или как бы вы это делали Нужно сделать такой вот компонентик Суть в чем - айтем посередине всегда чуть больше остальных (анимируется свайпами) Сам лист infinite - айтемы нужно добавлять в обе стороны свайпа 2 проблемы - анимация и infinite scroll в обе стороны

ну вот похоже что просто так это все невозможно встроить в иерархию обычных вьюх, вот и строят свою систему, по опыту asyncdisplaykit :)

Это в догонку, очень долго статью искал ) Вот эта система (она лежит в основе лэйаута в ios и она синхронная): https://developer.apple.com/documentation/uikit/uiview/1622482-layoutsubviews?language=objc То, что при этом сама отрисовка у них построена на слоях и скорей всего реальный рендеринг вытащен из UI потока, вообще не видно снаружи... Если что, вот здесь немного описано ещё https://www.objc.io/issues/3-views/advanced-auto-layout-toolbox/#the-layout-process (специально искал древнюю статью, т.к. в новых про это уже не вспоминают почти)

https://github.com/mnshkv/scroll-example @GeorgeWizeman @ivan3177

Так вот тут как раз оба пункта, если я правильно понял: 1 - допущение, что увеличенный айтем "не раздвигает" собой остальные, т.е. только transform 2 - оконность, да ) Хотя про п.1 я сейчас подумал, что теоретически можно было бы попробовать наложить на все айтемы ещё трансформ, сдвигающий их на константу: если слева от выделенного, то влево, если справа от выделенного, то вправо, а центральный сдвигать на 0, он и так скейлится. И получится более менее то, что надо, но такое либо в js считать, либо на reanimated писать наверное...

https://github.com/mnshkv/scroll-example @GeorgeWizeman @ivan3177

<TextInput style={styles.input} placeholder={'Введите текст...'} value={this.removeEmojis(this.state.message)} maxHeight={80} selectionColor={colors.accent_color} multiline textAlignVertical={"center"} onChangeText={(message) => this.handleShowWriting(message)} keyboardType={Platform.OS === 'android' ? 'email-address' : 'ascii-capable'} />

onChangeText={this.handleShowWriting}

Да, работает. но мою проблему не решает. думал может это дает нагрузку

Посоветуйте сервисы для тестирования приложения на реальных устройствах. Чтобы по деньгам более-менее. И можно было в автоматические тесты. Спасибо.

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

Да, работает. но мою проблему не решает. думал может это дает нагрузку

value={this.removeEmojis(this.state.message)} а тут какой-то особый кейс, при котором надо так делать? почему сразу в стейт не класть с removeEmojis?

либо в конструкторе через bind, либо при определении метода делать вот так: myMethod = () => { ... } вместо myMethod () { ... } при использовании хуков эти танцы с бубном не нужны и можно просто передавать функцию как пропс, без дополнительно обертки дополнительные обертки, читай, генерация функций во время рендера – плохо для памяти, GC отработает, конечно, но зачем лишний раз перегружать?

типа: const [data, setData] = useState() … value={data} onChangeText={setData} ?

типа: const [data, setData] = useState() … value={data} onChangeText={setData} ?

да, в функциональном компоненте и useState('')

Да, работает. но мою проблему не решает. думал может это дает нагрузку

я обычно внутри компонента создаю функцию, что-то типа const handleMyEvent = () => { setData(data) } и ее уже передаю в пропсы

а зачем в этом случае доп/ обертка?

а если надо что-то более универсальное? например, у нас несколько свойств стейта, не писать же каждый раз новую функцию? а что-то вроде handleEvent = (val, func) => { func(val) } без стрелочной функции уже не вызвать, ибо надо два аргумента передать

а что мешает сделать так? const handler = (val1, val2) => { ... } return <MyComponent onSomething={handler}/> универсальные коллбеки – довольно хреновая практика и поддерживаемость такого кода резко снижается. мест, где они были бы нужны, не так много

либо в конструкторе через bind, либо при определении метода делать вот так: myMethod = () => { ... } вместо myMethod () { ... } при использовании хуков эти танцы с бубном не нужны и можно просто передавать функцию как пропс, без дополнительно обертки дополнительные обертки, читай, генерация функций во время рендера – плохо для памяти, GC отработает, конечно, но зачем лишний раз перегружать?

выходит, на каждое свойство стейта отдельную функцию делать? что-то я не очень понял

При использовании хуков такие танцы с бубном не "не нужны", а попросту невозможны )

ну если про хуки говорить, то ты и так на каждое свойство стейта создаешь функцию через useState(). по сути там и свойств-то нет. каждый кусок стейта – отдельная переменная + сеттер к ней. здесь же вопрос в обработке событий компонента, говоря про функциональные компоненты, есть два подхода: <MyComponent onSomething={() => setData()}/> и const handler = (val1, val2) => { ... } <MyComponent onSomething={handler}/> глобально они ничем не отличаются, обоих случаях создается функция-обработчик, которая передается в компонент, порсто в первом случае эта функция создается в момент вызова компонента, во втором случае - заранее я считаю подход с объявлением функции прямо в пропсах "грязным". но это лично мое мнение и я стараюсь обработчики, передаваемые компоненту, всегда выносить в отдельные функции