Если мне кто-то скажет, что он написал свой адаптер для базы данных, или, прости Господи, свой движок для базы - я к этому даже не подойду.
В этом то и проблема. Вместо того, чтобы хотя бы поверхностно ознакомится с решением, прочитать в описании зачем автор написал свою, когда уже тыщи существуют (а там по-любому будет обоснование) – вы сразу категорически против. Такая категоричность вредит. Именно из-за нее у нас во фронтенде, библиотеку redux написаную лучшими ребятами из «книги лиц», выверенную, проверенную и т.д скачивают 11 000 000 раз в неделю, хотя объективно она проигрывает многим решениям примерно во всем. А результат этой быстрой и надежной разработки на проверенных библиотеках получается примерно как хабр, не грузим одновременно статью и комментарии, ибо тормозит.
А про временные затраты лучше говорить с цифрами в руках. "Достаточное" и "существенное" - это из области балета.
По моему очевидно, что создание объекта + его «заморозка», не может быть быстрее, или одинаково по скорости чем просто создание объекта.
Пожалуйста, кое-какие «цифры»:
В этом тесте мы просто создаем некоторое количество объектов и по разному из фризим. Результаты отличаются довольно сильно, но видно, что Object.freeze проигрывает и там и там.
В этом тесте я исключил обычный объект, а тест состоит из попытки изменить значение у «read-only» свойства внутри try/cacth с логированием текста ошибки.
Тут тоже, два разных бенчмарка показывают, что Object.freeze проигрывает.
Достаточно медленная, чтобы оказывать существенное влияние на производительность. Я, да и не только я, предлагаю внедрить "final". Само предложение описано как синтаксический сахар, но ясно, что если и реализуют, то точно не так, а «как надо», чтобы было быстро.
Наследование от Observable позволяет избежать проблем с наследованием вообще, и убирает необходимость переопределять свойства. Это делает observable чуть-чуть производительнее.
Чего именно хотелось бы? Сделать реактивным history? Это пару строк кода, для этого не нужна отдельная либа, и уж точно это не должно быть встроено в стейт-менеджер.
Ты поэтому свою зовел, чтобы быть в ней главный? ))
Конечно, в твоей песочнице $mol в лидерах. Готов вернуться к обсуждению, когда у твоих решений будет хоть какие-то количество скачиваний в npm, и когда он будут бенчаться на авторитетных ресурсах, например тут: https://krausest.github.io/js-framework-benchmark/index.html
А пока это пустой треп. «Я в своей песочнице самый лучший!» — поздравляю. Отличное достижение.
Даже не знаю с чего начать, и как себя сдерживать. Но попробую:
Песочница
Будь добр использовать то же что и все, а не кидать ссылки на сомнительные ресурсы где даже импорты на моле.
Вычисление всего до авторанов:
Вычисления как раза идут после autorun. Что логично, если читать документацию.
The autorun function accepts one function that should run every time anything it observes changes. It also runs once when you create the autorun itself.
Автораны работают. Конечно, ты написал максимально странный, бессмысленный и запутанный код, чтобы никому и в голову не пришло разобраться, лишь бы хайпа словить. Это в твоем стиле, конечно, но по факту, два свойства которые действительно участвуют в этих вычислениях это App.A и App.B, которые изначально 0. Все остальное гетеры которые зависят от кучи запутанного лапшикода и A с B.
autorun(() => console.log("A-B", App.A, App.B));
Добавь, запусти, и получишь «неработающий» autorun.
В этом то и проблема. Вместо того, чтобы хотя бы поверхностно ознакомится с решением, прочитать в описании зачем автор написал свою, когда уже тыщи существуют (а там по-любому будет обоснование) – вы сразу категорически против. Такая категоричность вредит. Именно из-за нее у нас во фронтенде, библиотеку redux написаную лучшими ребятами из «книги лиц», выверенную, проверенную и т.д скачивают 11 000 000 раз в неделю, хотя объективно она проигрывает многим решениям примерно во всем. А результат этой быстрой и надежной разработки на проверенных библиотеках получается примерно как хабр, не грузим одновременно статью и комментарии, ибо тормозит.
По моему очевидно, что создание объекта + его «заморозка», не может быть быстрее, или одинаково по скорости чем просто создание объекта.
Пожалуйста, кое-какие «цифры»:
В этом тесте мы просто создаем некоторое количество объектов и по разному из фризим. Результаты отличаются довольно сильно, но видно, что Object.freeze проигрывает и там и там.
В этом тесте я исключил обычный объект, а тест состоит из попытки изменить значение у «read-only» свойства внутри try/cacth с логированием текста ошибки.
Тут тоже, два разных бенчмарка показывают, что Object.freeze проигрывает.
Достаточно медленная, чтобы оказывать существенное влияние на производительность.
Я, да и не только я, предлагаю внедрить "final". Само предложение описано как синтаксический сахар, но ясно, что если и реализуют, то точно не так, а «как надо», чтобы было быстро.
Object.freeze медленная операция. Вы смотрели деградацию производительности после внедрения этого решения?
На мой взгляд, это очень радикальное решение с сомнительными плюсами.
Кажется, что там где действительно нужна защита, проще использовать что-то такое:
С рабочего не разрешают загружать картинки
https://stackblitz.com/edit/vitejs-vite-8qwkxu?file=src%2Fmain.ts&terminal=dev
"kr-observable": "^1.0.21"
Исправлено
В JS нет деструкторов, а то, что можно реализовать самостоятельно в качестве деструктора не гарантирует что GC пройдется и очистит.
У мобх есть onBecomeObserved и onBecomeUnobserved для таких задач.
Спасибо)
Наследование от Observable позволяет избежать проблем с наследованием вообще, и убирает необходимость переопределять свойства. Это делает observable чуть-чуть производительнее.
Спасибо. Не обращал внимание раньше. Починю.
Чего именно хотелось бы? Сделать реактивным history? Это пару строк кода, для этого не нужна отдельная либа, и уж точно это не должно быть встроено в стейт-менеджер.
Спасибо. Надо добавить такое поведение в observable.
Не совсем понял, можешь привести пример?
наблюдатели foo тригернутся если значение foo поменяется, а это произойдет если изменится this.a или this.b (или оба).
В solid сигналы
const [value] = createSignal(0)
Чтение value()
Его не нужно искать.
get foo() { this.a + this.b } // computed
Ты поэтому свою зовел, чтобы быть в ней главный? ))
Конечно, в твоей песочнице $mol в лидерах. Готов вернуться к обсуждению, когда у твоих решений будет хоть какие-то количество скачиваний в npm, и когда он будут бенчаться на авторитетных ресурсах, например тут: https://krausest.github.io/js-framework-benchmark/index.html
А пока это пустой треп. «Я в своей песочнице самый лучший!» — поздравляю. Отличное достижение.
Боже, это великолепно.
Даже не знаю с чего начать, и как себя сдерживать. Но попробую:
Песочница
Будь добр использовать то же что и все, а не кидать ссылки на сомнительные ресурсы где даже импорты на моле.
Вычисление всего до авторанов:
Вычисления как раза идут после autorun. Что логично, если читать документацию.
Посмотри логи: https://codesandbox.io/p/sandbox/mdm9cp
Автораны не работают
Автораны работают. Конечно, ты написал максимально странный, бессмысленный и запутанный код, чтобы никому и в голову не пришло разобраться, лишь бы хайпа словить. Это в твоем стиле, конечно, но по факту, два свойства которые действительно участвуют в этих вычислениях это App.A и App.B, которые изначально 0. Все остальное гетеры которые зависят от кучи запутанного лапшикода и A с B.
Добавь, запусти, и получишь «неработающий» autorun.
Мне не нравится атомы и сигналы как концепция.
Я бы сказал так: Solid как React, но он не реакт. Кроме того, Solid использует сигналы, а писать на них, лично мне — не нравится.