Не уверен что следует вам ответить. Пример зависимых валидаторов сделаю во второй статье. Про валидацию на бэке — первый абзац этой статьи. Что выбранный мной подход не прост, не очевиден и не является "первым выбором" — да, именно по этому я его взял и исследую.
Можно и разумно использовать json schema или решения с аналогичным подходм, согласен. Я, просто, решил подойти к вопросу чуть шире и с чуть менее серьёзным лицом.
Если нужно сходить в БД — это в любом случае не фронтовый валидатор, "не наш случай". "Одно поле зависит от другого" — это задача валидации, "появляются доп поля" — задача уже вне валидации. Я начал вторую часть статьи, реализация того же, но на wasm, попробую проанализировать в процессе случай с зависимыми полями, как он соотносится с идеей "один код валидации на фронте и бэке".
А вот это хороший вопрос. Не думал, что делать для 3+ участников. Подумаю. Что касается схемы, это понятно, что в 95% случаев использование библиотек с единой конфигурацией наиболее разумно. Я исследую вопрос с другого угла, хочу чтобы валидатор был не декларативными правилами, а исполнимым кодом. Так гибкость выше чем у любого конструктора правил.
А я, видимо, попробую так сделать и оформить статьёй. Алаверды от бэка, так сказать. Ну и надо, кажется, проговорить явно, что это болше забавный эксперимент, чем HOWTO.
Да, безусловно. Приминимость разных подходв зависит от размера проекта и сложности валидаторов. Мой эксперимент, как правилнее сказать, - "на максималочках" - на JS-то точно любой валидатор можно написать. Ну и так веселее :)
Согласен. Без вопросов. Есть и другие заходы на проблему, в том числе и два конструктора валидаторов из единого конфига. И использование третьего языа, который можно скомпилировать в язык и фронта и бэка. Можно посравнивать эти подходы на практике, но это уже будет другая статья.
Т.е. тачпад для меня не очень — долго целюсь и часто мажу (случайные клики).
(Интересных результатов мне накликали за эти три дня, надо бы их обобщить и выложить...)
Хороший вопрос! На Win, Lin и Mac — всё отлично, а вот на Haiku я трекбол стараюсь не использовать — настроить скрол невозможно. С точки зрения любой ОС трекбол — просто мышка.
Рельсы не моя тема, но посмотреть подход будет интересно. Спасибо за ссылку.
Не уверен что следует вам ответить. Пример зависимых валидаторов сделаю во второй статье. Про валидацию на бэке — первый абзац этой статьи. Что выбранный мной подход не прост, не очевиден и не является "первым выбором" — да, именно по этому я его взял и исследую.
Можно и разумно использовать json schema или решения с аналогичным подходм, согласен. Я, просто, решил подойти к вопросу чуть шире и с чуть менее серьёзным лицом.
Спасибо за ссылку. Интересная штука, поизучаю.
Если нужно сходить в БД — это в любом случае не фронтовый валидатор, "не наш случай". "Одно поле зависит от другого" — это задача валидации, "появляются доп поля" — задача уже вне валидации. Я начал вторую часть статьи, реализация того же, но на wasm, попробую проанализировать в процессе случай с зависимыми полями, как он соотносится с идеей "один код валидации на фронте и бэке".
А вот это хороший вопрос. Не думал, что делать для 3+ участников. Подумаю.
Что касается схемы, это понятно, что в 95% случаев использование библиотек с единой конфигурацией наиболее разумно. Я исследую вопрос с другого угла, хочу чтобы валидатор был не декларативными правилами, а исполнимым кодом. Так гибкость выше чем у любого конструктора правил.
А я, видимо, попробую так сделать и оформить статьёй. Алаверды от бэка, так сказать. Ну и надо, кажется, проговорить явно, что это болше забавный эксперимент, чем HOWTO.
Спасибо за ссылочку. Для того и общаемся, чтобы в комментариях насыпали того, на что сам не сразу наскочишь.
Да, безусловно. Приминимость разных подходв зависит от размера проекта и сложности валидаторов. Мой эксперимент, как правилнее сказать, - "на максималочках" - на JS-то точно любой валидатор можно написать. Ну и так веселее :)
Согласен. Без вопросов. Есть и другие заходы на проблему, в том числе и два конструктора валидаторов из единого конфига. И использование третьего языа, который можно скомпилировать в язык и фронта и бэка. Можно посравнивать эти подходы на практике, но это уже будет другая статья.
среднее время клика: 882.5 — 1080.98
точность клика: 1.00
Trackball (x3 прогона)
среднее время клика: 960.16 — 969.5
точность клика: 0.92
Mouse (x3 прогона)
среднее время клика: 695.7 — 818.48
точность клика: 0.96
Touchpad (x4 прогона)
среднее время клика: 1104.18 — 1326.08
точность клика: 0.76
Т.е. тачпад для меня не очень — долго целюсь и часто мажу (случайные клики).
(Интересных результатов мне накликали за эти три дня, надо бы их обобщить и выложить...)
Попробуйте поискать на сайте производителя, в техподдержку ещё можно написать.