Попробуйте самостоятельно реализовать валидацию формы из примера в статье
Эмм...
input type="text", гарантирует что введенные данные – строка.
input type="number" + event.target.valueAsNumber гарантирует что введенные данные – число.
С min="3000000" при вводе чего-то меньше этого числа, event.target.validity.valid будет false, что проще + синхронно в сравнении с v.parseAsync(NameSchema, 'jq')
Проверять target.validity можно на onInput, onChange, onBlur или submit. Что именно тут нужно реализовывать?
Я все еще не понимаю, зачем такие валидаторы нужны фронтенду.
Можно представить, что фронтенд-приложение состоит из двух типов данных – те которые пришли из единственного источника истины (БД), и те которые пользователь вводит.
Это значит, что данные полученные по API нужно валидировать поверхностно, то есть убедится что мы получили строку а не число, или массив строк а не чисел и т.д. Проверять в джейсоне, что емэйл isEmail не нужно, это уже проверили перед сохранением.
Второй тип данных это те, что пользователь вводит. Сама идея валидировать их таким образом, звучит странно. Например, у нас есть форма с тремя полями: имя, возраст и емэйл.
Варианты:
На каждый onChange валидируем, и показываем ошибку если валидация не прошла
Перед отправкой формы валидируем, и показываем ошибку если валидация не прошла
... какие-то еще варианты ...
Все эти варианты – пост-валидация. Мы дали пользователю ввести данные, а потом ругаемся. Только непонятно зачем. Все инпуты уже содержат логику валидации. Есть атрибуты типа min, max, pattern и т.д., на каждый onChange можно проверить соответствуют ли данные нужному паттерну просто ифом:
if (event.target.validity.valid) {
// сохраняем ввод
}
Если данные некорректны, мы их просто не присваиваем, а пользователю указываем на то, то данные не валидны.
Если мне кто-то скажет, что он написал свой адаптер для базы данных, или, прости Господи, свой движок для базы - я к этому даже не подойду.
В этом то и проблема. Вместо того, чтобы хотя бы поверхностно ознакомится с решением, прочитать в описании зачем автор написал свою, когда уже тыщи существуют (а там по-любому будет обоснование) – вы сразу категорически против. Такая категоричность вредит. Именно из-за нее у нас во фронтенде, библиотеку 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
А пока это пустой треп. «Я в своей песочнице самый лучший!» — поздравляю. Отличное достижение.
Эмм...
input type="text", гарантирует что введенные данные – строка.
input type="number" + event.target.valueAsNumber гарантирует что введенные данные – число.
С min="3000000" при вводе чего-то меньше этого числа, event.target.validity.valid будет false, что проще + синхронно в сравнении с
v.parseAsync(NameSchema, 'jq')Проверять target.validity можно на onInput, onChange, onBlur или submit. Что именно тут нужно реализовывать?
Это не сложно реализовать без валидатора, как упрощенный пример https://codepen.io/s5604/pen/zxxPxLd
А скоро в css attr() заработает для всех нужд, а не только для content. Будет еще проще
Я все еще не понимаю, зачем такие валидаторы нужны фронтенду.
Можно представить, что фронтенд-приложение состоит из двух типов данных – те которые пришли из единственного источника истины (БД), и те которые пользователь вводит.
Это значит, что данные полученные по API нужно валидировать поверхностно, то есть убедится что мы получили строку а не число, или массив строк а не чисел и т.д. Проверять в джейсоне, что емэйл isEmail не нужно, это уже проверили перед сохранением.
Второй тип данных это те, что пользователь вводит. Сама идея валидировать их таким образом, звучит странно. Например, у нас есть форма с тремя полями: имя, возраст и емэйл.
Варианты:
На каждый onChange валидируем, и показываем ошибку если валидация не прошла
Перед отправкой формы валидируем, и показываем ошибку если валидация не прошла
... какие-то еще варианты ...
Все эти варианты – пост-валидация. Мы дали пользователю ввести данные, а потом ругаемся. Только непонятно зачем. Все инпуты уже содержат логику валидации. Есть атрибуты типа min, max, pattern и т.д., на каждый onChange можно проверить соответствуют ли данные нужному паттерну просто ифом:
Если данные некорректны, мы их просто не присваиваем, а пользователю указываем на то, то данные не валидны.
Можем показать пользователю текст ошибки
Простой пример https://codesandbox.io/p/sandbox/frljd9
В этом то и проблема. Вместо того, чтобы хотя бы поверхностно ознакомится с решением, прочитать в описании зачем автор написал свою, когда уже тыщи существуют (а там по-любому будет обоснование) – вы сразу категорически против. Такая категоричность вредит. Именно из-за нее у нас во фронтенде, библиотеку 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
А пока это пустой треп. «Я в своей песочнице самый лучший!» — поздравляю. Отличное достижение.