Анимировать можно что захочешь, числа (длину фигуры, например), строки (эффект печатания текста, например) и так далее

в нас є Animated, яикй не ідеальний, але можливо має якісь прикольні ідеї

Загалом в тебе є якась в’юха — то саме шо твій shape. У неї є набір пропертів, які можна анімувати — всі шо приконекчені до нативних пропертів, типу стилів, а також деяких буліанів, тексту і тд

У тебе є Animated.Value, який є базовим класом для змінної, яку можна анімувати, її ти маєш прокинути як значення конкретної властивості, але ти можеш це скіпнути, думаючи що сходу є якийсь набір значень, які можуть бути анімованими, думаю так чи інакше ти зможеш виділити якийсь пул їх, не обов’язково стилі

і є Animated.timing — це функція, яка приймає Animated.Value, яку ти хоч анімувати, а також конфіг того, як саме ти то хоч зробити

під капотом (я зараз буду більше про андроїд говорити, хоч реалізації дуже схожі) ж клас, який відповідає за конкретний Animated.Value, є абстрактний клас AnimationDriver, від якого наслідуються інші, наприклад FrameBasedAnimationDriver, він полем має ту AnimatedValue, яку зараз анімує, а є, для прикладу, InterpolationAnimatedDriver, який приймає як коніг для інтерполяції, так значення яке інтерполюють

тобто драйвер завжди анімує лиш один Animated.Value, в тебе це може бути конкретне поле Shape

проте як показує практика написання анімацій, далеко на такому і так не заїдеш, тому шо ти захочеш (або твій користувач) писати кастумну логіку на кожен фрейм (саме через це, існують такі проекти як Reanimated), де в більшій мірі в тебе є таке поняття як Clock, ти його запускаєш, і на основі нього вже мутиш всякі timing/spring. Важливою складовою Clock є те, що ти можеш оголосити один для декількох анімацій (драйверів), відповідно вони точно будуть синхронізовані, тому що всі апдейти будуть в одному фреймі

Ну вот твой Animated.Value у меня просто свойство объекта, без обертки.

Драйвер умеет их анимировать эти свойства. Но он не знает какие именно свойства будут анимироваться, это будет решено в конфиге пользователя.

Но ты сильно глубоко идёшь и не в тему. Вопрос был только в типах и object[property] = value

Мій посил був в тому, що драйвер анімує конкретну властивість Shape, відповідно таким чином можна уникнути отакої дуже загальної конструкції в принципі)

Імхо, часто проблема не в TS, а в тому що ми звикли до JS, де такий метод, який редагує все-все більш ніж звичний

В іншому випадку оце дуже норм

Абстракция в виде Animated.Value тебя не спасёт в TS, ты просто эту проблему переложил бы на Animated.Value и там бы у тебя было “any”

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

Не правда, це завжди може бути генерік

Власне в анімейтед то абстрактний клас

А почему any в этом случае плохо? Если в действительности any это абсолютно все что угодно - т.е. соответствует реквайрменту. Т.е. для себя хочу выяснить почему там может быть все что угодно, но не any?

any не позволяет последующую валидацию типов, дальше по коду

Хороший аргумент

Спасибо

Надо юзать unknown

1) то что Лёша сказал, any тебе рубит полностью любой тайпчек
2) constraints у меня всё-таки есть - мне нужно не object[anyRandomPropertyName] = value а object[propertiesFromTypeA & propertiesFromTypeB & anyPossiblePropertiesFromFutureClasses] = value as ExactlyThePropertyTypeWeAssignTo - тайпчек никуда не пропадает
3) я принципиально не использую "размазанные" типы в языке, где можно использовать и описывать более определенные и для этих целей у меня в TS указано, что не должно быть неявных any, а в линтере указано, чтобы не было явных any :)

ну и если бы я захотел поведение any, то я бы на JS писал и не парился с сетапом TS

Ну первый пункт вот прям все и прояснил. Спасибо.

Гляньте цацку завозят https://www.infoq.com/news/2020/03/TornadoVM-QCon-London/

Там если что нода тоже сапортится

Вітаю панове. Може хтось за пиво допомогти вирішити пару питань на svelte для опенсорсного проекту (activitypub) ☺️