Там много чего нет из того, что можно найти где-нибудь ещё.
Я много труда вложил в то, чтобы сохранить библиотеку простой: и по структуре, и в использовании. Там только то, что нам реально нужно в нашем проекте, и ничего лишнего.
На самом деле с пользовательской точки зрения это намного удобнее (хотя свои минусы тоже есть). Вместо кучи combineN и RebuilderN был бы один ComputedValue и Rebuilder. Потому, что постоянно указывать и менять цифры, прописывать для всего типы и все это вручную, ну такое...
Цифры менять вручную действительно надо, но это быстро и просто. Как уже написал выше, семейства combineN, RebuilderN, ComputedValueN нужны для строгой типизации. Преимущества от её использования явно перевешивают небольшое неудобство от того, что иногда придётся подправить пару цифр.
Вы переизобрели MobX)
"Продать" относительно Stream и rxdart конечно получилось, но сравнивать, на мой взгляд, нужно не с ними, а с MobX и его аналогами, и возможно даже с Riverpod.
Может быть, в каком-то смысле. Во всех инструментах работы с реактивностью можно найти похожие паттерны.
Мне совершенно не нравится как в MobX предлагается встраивать поддержку реактивности в свой класс. А также что там используется кодогенерация.
Сравнивать можно. Но я бы не говорил о переизобретении MobX. Некоторые ключевые идеи (как минимум ориентация на иммутабельность underlying типа и независимость underlying типа от самой концепции Value) принципиально другие.
Строго говоря у StreamController -а нет метода dispose
Да, вы правы, :) поправлю.
Сложно понять, что тут имеется ввиду. Видимо, то что вся изменения будут переданы в колбек? На мой взгляд такое редко нужно, и чаще всего это вычисления впустую и по умолчанию лучше вызывать колбек один раз и с последним значением.
В некоторых случаях важно в обработчике проследить всю историю изменения зависимых Value, особенно в случае множественной подписки. Обработчики вызываются асинхронно, поэтому к моменту запуска метода значения Value могут уже несколько раз измениться. Вся система работает более предсказуемо, если в обработчик передавать полную историю изменений. Если этого не делать, в случае множественной подписки гарантированы долгие часы увлекательной отладки.
Наверное лучше было бы использовать предикат? В таком случае возможности были бы шире.
Не лучше. Операция сравнения определяется underlying типом, это его зона ответственности. Более широкие возможности тут не нужны, потому что усложняют логику работы кода. В случае, когда понадобился предикат, возможно стоит использовать трансформацию.
Пример с combine2 не компилируется. Зачем делать в CombinedValueSubscription метод отмены с типом Future, если ассинхронность не используется?
Это хвосты от предыдущей версии, где было гораздо больше асинхронности. Поправлю, спасибо.
Создавать новый экземпляр Stopwatch на каждый вызов notify несколько накладно.
Замер скорости старта остался от предыдущих версий. Сейчас он по факту более не нужен. Спасибо.
На использование микротасков должны быть какие-то веские причины, у вас много работы выполняется, т.е. это явно не должен быть микротаск, иначе привет подвисания, особенно на слабых устройствах. Настолько много, что вы даже замеряете время выполнения. Это не то что звоночек, это колокол!
В микротаске обработчики только запускаются. Он не ждёт окончания их выполнения. Единственное что может подвесить микротаск, так это тяжёлый синхронный обработчик.
Надо кстати поэкспериментировать, может уже и без микротасков будет нормально работать.
Очевидно, что transformer может быть накладен для вычисления, и лучше кэшировать значение.
Не совсем так. Кешировать значение где? Непосредственно в экземпляре TransformedValue? А как тогда этот кэш инвалидировать? Т.е. в TransformedValue нужна подписка на оригинальный Value, даже если у TransformedValue нет своих подписчиков. Эту подписку надо потом как-то отменять.
Я пробовал сделать такой кэш, ничего хорошего из этого не получилось.
Опять же на практике трансформации как правило предельно простые и быстрые. А если это не так, то это вопрос к пользовательскому коду почему.
Вы в нескольких местах что-то подобное пишете, но по факту это не совсем правильно. По-хорошему ваш Value так же должен предоставлять метод dispose или его аналог, т.к. во-первых, чтобы можно было отписаться от все подписок, с текущим апи это сделать нельзя.
Так сделано специально. Отписка - это зона ответственности подписчиков.
Во вторых наследники этого класса используют, например Timer, который тоже никак не остановить, насколько я понял и он будет тикать, хотя уже может быть давно не нужен.
В TimeoutValue таймер срабатывает единожды, ничего страшного в этом нет. В ThrottleValue и DebounceValue таймер привязан к экземпляру подписки и отменяется вместе с ней. В PeriodicValue таймер общий для всех подписок текущего экземпляра PeriodicValue, но он отменяется, когда все подписки отменены. Других бесконечно тикающих таймеров вроде нет.
Методы combineN() хороши тем, что обработчики получаются строго типизированными.
На случай, когда нужно просто реагировать на список ReadonlyValue, заготовлен метод combine(), который как раз делает именно то что вы описали. В моей практике такие юзкейсы очень редки, по пальцам одной руки пересчитать.
Моя конфигурация:
Стол Ikea Bekant с электроприводом.
Дорожка для ходьбы, аналогичная дорожке от Xiaomi, макс. скорость 6 км/ч.
Стул Ikea JÄRVFJÄLLET (но Markus лучше), используется в сидячем режиме рабочего места.
На столе ноутбук, выше него большой монитор. Отдельная мышь.
Это рабочее место я собрал 3 месяца назад.
Раньше также пробовал работу просто стоя и сидя на коленном стуле. От первого болела спина, от второго колени.
Сперва общие впечатления.
В отличие от работы просто стоя, спина не болит и не затекает. При ходьбе устаёшь явно меньше, чем если просто стоять. Однако часа через 2 всё-таки хочется присесть отдохнуть.
Босиком, да и даже в носках ходить неудобно. Хожу в очень лёгких кроссовках.
В жаркую погоду, когда сидеть ещё терпимо, ходить становится некомфортно жарко. Так что на период жары рабочее место становится полностью сидячим. Зато может зимой дополнительная мотивация ходить появится.
Набирать текст и пользоваться мышкой возможно на скоростях до 2 км/ч, оптимально 1.75 км/ч. Быстрее — мышка дёргается, и это мешает работать.
В режиме видеоконференции можно и 2.5 км/ч поставить. Дорожку кстати через микрофон собеседникам слышно, проблема решается уменьшение коэффициента усиления микрофона в настройках ОС. Самому логично использовать наушники.
Скорости указаны верные. По улице хожу 5-7 км/ч. Дома восприятие скорости другое.
Хождение мешает высокоинтеллектуальной работе. Когда придумываю новую архитектуру кода или отлаживаю особенно хитрый баг (я мобильный разработчик), приходится садиться на стул, иначе мысли разбегаются. Входить в состояние потока на дорожке и совершенно забывать о факте хождения я пока не научился.
Средне- и слабо-интеллектуальной работе хождение не мешает.
Дорожку продолжать использовать планирую, особенно когда попрохладнее станет.
Как вариант можно летать по кругу на малой постоянной высоте, дожигая остаток топлива. Перегрузку при этом можно сделать практически любой (>= 1G) за счёт центробежной силы.
Там много чего нет из того, что можно найти где-нибудь ещё.
Я много труда вложил в то, чтобы сохранить библиотеку простой: и по структуре, и в использовании. Там только то, что нам реально нужно в нашем проекте, и ничего лишнего.
Спасибо за конструктивный фидбек!
Цифры менять вручную действительно надо, но это быстро и просто. Как уже написал выше, семейства combineN, RebuilderN, ComputedValueN нужны для строгой типизации. Преимущества от её использования явно перевешивают небольшое неудобство от того, что иногда придётся подправить пару цифр.
Может быть, в каком-то смысле. Во всех инструментах работы с реактивностью можно найти похожие паттерны.
Мне совершенно не нравится как в MobX предлагается встраивать поддержку реактивности в свой класс. А также что там используется кодогенерация.
Сравнивать можно. Но я бы не говорил о переизобретении MobX. Некоторые ключевые идеи (как минимум ориентация на иммутабельность underlying типа и независимость underlying типа от самой концепции Value) принципиально другие.
Да, вы правы, :) поправлю.
В некоторых случаях важно в обработчике проследить всю историю изменения зависимых Value, особенно в случае множественной подписки. Обработчики вызываются асинхронно, поэтому к моменту запуска метода значения Value могут уже несколько раз измениться. Вся система работает более предсказуемо, если в обработчик передавать полную историю изменений. Если этого не делать, в случае множественной подписки гарантированы долгие часы увлекательной отладки.
Не лучше. Операция сравнения определяется underlying типом, это его зона ответственности. Более широкие возможности тут не нужны, потому что усложняют логику работы кода. В случае, когда понадобился предикат, возможно стоит использовать трансформацию.
Это хвосты от предыдущей версии, где было гораздо больше асинхронности. Поправлю, спасибо.
Замер скорости старта остался от предыдущих версий. Сейчас он по факту более не нужен. Спасибо.
В микротаске обработчики только запускаются. Он не ждёт окончания их выполнения. Единственное что может подвесить микротаск, так это тяжёлый синхронный обработчик.
Надо кстати поэкспериментировать, может уже и без микротасков будет нормально работать.
Не совсем так. Кешировать значение где? Непосредственно в экземпляре TransformedValue? А как тогда этот кэш инвалидировать? Т.е. в TransformedValue нужна подписка на оригинальный Value, даже если у TransformedValue нет своих подписчиков. Эту подписку надо потом как-то отменять.
Я пробовал сделать такой кэш, ничего хорошего из этого не получилось.
Опять же на практике трансформации как правило предельно простые и быстрые. А если это не так, то это вопрос к пользовательскому коду почему.
Так сделано специально. Отписка - это зона ответственности подписчиков.
В TimeoutValue таймер срабатывает единожды, ничего страшного в этом нет. В ThrottleValue и DebounceValue таймер привязан к экземпляру подписки и отменяется вместе с ней. В PeriodicValue таймер общий для всех подписок текущего экземпляра PeriodicValue, но он отменяется, когда все подписки отменены. Других бесконечно тикающих таймеров вроде нет.
Методы combineN() хороши тем, что обработчики получаются строго типизированными.
На случай, когда нужно просто реагировать на список ReadonlyValue, заготовлен метод combine(), который как раз делает именно то что вы описали. В моей практике такие юзкейсы очень редки, по пальцам одной руки пересчитать.
Моя конфигурация:
Стол Ikea Bekant с электроприводом.
Дорожка для ходьбы, аналогичная дорожке от Xiaomi, макс. скорость 6 км/ч.
Стул Ikea JÄRVFJÄLLET (но Markus лучше), используется в сидячем режиме рабочего места.
На столе ноутбук, выше него большой монитор. Отдельная мышь.
Это рабочее место я собрал 3 месяца назад.
Раньше также пробовал работу просто стоя и сидя на коленном стуле. От первого болела спина, от второго колени.
Сперва общие впечатления.
В отличие от работы просто стоя, спина не болит и не затекает. При ходьбе устаёшь явно меньше, чем если просто стоять. Однако часа через 2 всё-таки хочется присесть отдохнуть.
Босиком, да и даже в носках ходить неудобно. Хожу в очень лёгких кроссовках.
В жаркую погоду, когда сидеть ещё терпимо, ходить становится некомфортно жарко. Так что на период жары рабочее место становится полностью сидячим. Зато может зимой дополнительная мотивация ходить появится.
Набирать текст и пользоваться мышкой возможно на скоростях до 2 км/ч, оптимально 1.75 км/ч. Быстрее — мышка дёргается, и это мешает работать.
В режиме видеоконференции можно и 2.5 км/ч поставить. Дорожку кстати через микрофон собеседникам слышно, проблема решается уменьшение коэффициента усиления микрофона в настройках ОС. Самому логично использовать наушники.
Скорости указаны верные. По улице хожу 5-7 км/ч. Дома восприятие скорости другое.
Хождение мешает высокоинтеллектуальной работе. Когда придумываю новую архитектуру кода или отлаживаю особенно хитрый баг (я мобильный разработчик), приходится садиться на стул, иначе мысли разбегаются. Входить в состояние потока на дорожке и совершенно забывать о факте хождения я пока не научился.
Средне- и слабо-интеллектуальной работе хождение не мешает.
Дорожку продолжать использовать планирую, особенно когда попрохладнее станет.
Хостится в Швейцарии.
$10 в месяц за каждый email-адрес, можно подключить почту для своего домена.
Open source, так что можно поставить всю эту кухню на собственных сервер и пользоваться бесплатно.
Шифрования на стороне клиента нет.