На всякий случай, можно не просить всех добавлять конфигурацию:
npm config set prefer-dedupe true
А создать на уровне проекта файл .npmrc и в нем прописать prefer-dedupe=true. Кажется, это немного легче и убирает человеческий фактор.
Заодно поделюсь своими наблюдениями: prefer-dedupe работает хуже, чем если бы просто после манипуляций с зависимостями выполнить отдельно команду npm ddp .
Что бы части кода имели возможность попасть под "нож" во время сборки, код должен быть не связанным. А этим как раз грешит Zod. Иными словами, возможности webpack тут не при чем.
транслировать юным разработчикам – иди в npm за новой либой в любой непонятной ситуации
Вы рекомендуете избегать лишних зависимостей, но при этом "сходили в npm" что бы установить библиотеку kr-observable вместо нативных возможностей React. Это кажется не совсем последовательным.
Тогда мы берем это же значение, и отправляем запрос на сервер чтобы создать этого пользователя. Тут вопрос «зачем» куда более уместен.
Если рассматривать это в отрыве от конкретного бизнес-процесса, то может показаться действительно абсурдным. Однако это довольно известный паттерн, который встречается повсеместно. Например, создание нового репозитория на GitHub.
Конечно, если мы говорим о небольших приложениях, которые разрабатывает один человек, то в этом случае действительно можно задуматься, не будет ли это избыточным.
Но, как говорится, "что знают двое — уже не секрет". А когда код пишут два и более разработчика, рано или поздно неизбежно возникают ошибки — человеческий фактор никто не отменял.
Более того, современные веб-приложения часто работают с двумя десятками разных API, особенно если мы говорим о микросервисной архитектуре. В таких условиях защита нашего приложения становится не просто желательной, а обязательной.
Вы абсолютно правы — технически всё можно реализовать вручную. Но если 1 килобайт кода способен убрать рутину, ускорить разработку и даже позаботиться о типах за вас. Разве не стоит попробовать?
К тому же, валидацию можно гибко настраивать — запускать не только при отправке формы, но и на любых других событиях, будь то изменение поля (onChange) или потеря фокуса (onBlur).
Попробуйте самостоятельно реализовать валидацию формы из примера в статье - с приведением типов и проверкой совпадения полей. А затем сделайте то же самое с помощью Valibot.
Если после этого я не смогу вас убедить - тогда, пожалуйста, примите мои извинения за ваше потраченное время.
Правильно ли я понимаю, что вы предлагаете подключить весь Zod (14,33 KB) вместо использования Valibot и tree-shaking? Можете пояснить, почему такой вариант предпочтительнее?
Всё верно. Я намеренно исключил их упоминание из статьи, чтобы сосредоточить внимание читателя на различиях между Zod и Valibot.
Что касается поддержки – базовые сценарии работы валидатора на моем опыте были покрыты на 100%. Однако, безусловно, могут быть edge-кейсы, где другой инструмент окажется более удобным.
Есть подозрение, что с серверными компонентами вы напутали. Выдержка из документации.
There is no directive for Server Components.
A common misunderstanding is that Server Components are denoted by "use server", but there is no directive for Server Components. The "use server" directive is used for Server Functions.
При всем уважении, но зачем вы приплетаете svg сюда и уходите в дебри? Анализируя все ваши "замечания", у меня складывается впечатление что название статьи и вступление полностью проигнорировано.
А если объективно, то вы предлагаете каждому фронтендеру покупать лицензию фотошопа? Более того, статья не про выбор инструмента, чем сжимать и ресайзить фотографии, а в целом о подходе и правилах работы с картинками, на что наличие фотошопа не влияет.
Оригинальное изображение взятое из макета без каких-либо модификаций. К сожалению я не понимаю, какую ценность даст читателю ссылка на картинку, добавить её что бы что?
Таблица служит показателем того, что произошло с весом картинки после ресайза и оптимизации.
Бесконечно с вами согласен, но есть нюанс, доклад был с уклоном на CI (если я не смог донести эту мысль, то извините), по этой причине такие опции как кэш, гит-хуки не упоминались. В целом, если правильно настроить IDE, то запускать локально линтинг не придется, тогда и кэш не будет нужен.
По той же ссылке предоставленной @nin-jin, Дэн пишет что by default они ничего не будут патчить. И в исходном коде react 18.2.0, нет ничего связанного с cache.
React Testing Library - устраивает более чем, мы на него переехали с enzyme. Изъянов в нем не нашли, даже стало немного приятней тесты писать, но это конечно субъективно.
По поводу vite, до него к сожалению руки еще не дошли. Очень хочу протестировать до конца swc и понять чем придется пожертвовать, если babel отключим. А потом уже esbuild, vite и может еще что-то интересное подвернется.
На всякий случай, можно не просить всех добавлять конфигурацию:
А создать на уровне проекта файл
.npmrcи в нем прописатьprefer-dedupe=true. Кажется, это немного легче и убирает человеческий фактор.Заодно поделюсь своими наблюдениями:
prefer-dedupeработает хуже, чем если бы просто после манипуляций с зависимостями выполнить отдельно командуnpm ddp.Что бы части кода имели возможность попасть под "нож" во время сборки, код должен быть не связанным. А этим как раз грешит Zod. Иными словами, возможности webpack тут не при чем.
Вы рекомендуете избегать лишних зависимостей, но при этом "сходили в npm" что бы установить библиотеку kr-observable вместо нативных возможностей React. Это кажется не совсем последовательным.
Позвольте мне ненадолго побыть тестировщиком:
Поле email принимает значение
test@inbox, кажется что не хватает доменной части.Поля для пароля: если ввести
1в оба поля, ошибка у второго поля не соответствует действительности.Здорово, что вы предусмотрели случай с NaN. Но, как вы думаете, многие ли разработчики действительно добавляют такую проверку?
Это всё не к тому, чтобы докопаться, а к тому, что валидация формы — не такая уж простая задача, как может показаться на первый взгляд.
Если рассматривать это в отрыве от конкретного бизнес-процесса, то может показаться действительно абсурдным. Однако это довольно известный паттерн, который встречается повсеместно. Например, создание нового репозитория на GitHub.
Вы тут сравниваете асинхронную валидацию доступности условного
usernameв БД с валидацией минимального значения введенного в поле. Зачем?сделать проверку поля
emailна валидный email;в поле
ageсделать проверку на то, что введенное значение является числом, имеет значение>= 18иtypeof === 'number';сделать проверку поля
passwordна то, что длинна пароля от 4 до 12 символов;сделать проверку поля
repeatPasswordна строгое равенство с полемpassword;под каждую из ошибок указанных в пункте 1, 2, 3, 4 отдавать user-friendly текстовое описание того, в чем не прав пользователь;
обеспечить механизм запрета сабмита формы пока не будут выполнены пункты 1, 2, 3, 4;
как бонус (который из коробки несет в себе Valibot/Zod и т.п. библиотеки), типизировать эти данные;
закинуть ваш полностью работающий пример на codepen.
Был не прав, нужно было сразу четко обозначить требования к форме, валидации и её последующей отправки на сервер.
Конечно, если мы говорим о небольших приложениях, которые разрабатывает один человек, то в этом случае действительно можно задуматься, не будет ли это избыточным.
Но, как говорится, "что знают двое — уже не секрет". А когда код пишут два и более разработчика, рано или поздно неизбежно возникают ошибки — человеческий фактор никто не отменял.
Более того, современные веб-приложения часто работают с двумя десятками разных API, особенно если мы говорим о микросервисной архитектуре. В таких условиях защита нашего приложения становится не просто желательной, а обязательной.
Вы абсолютно правы — технически всё можно реализовать вручную. Но если 1 килобайт кода способен убрать рутину, ускорить разработку и даже позаботиться о типах за вас. Разве не стоит попробовать?
К тому же, валидацию можно гибко настраивать — запускать не только при отправке формы, но и на любых других событиях, будь то изменение поля (
onChange) или потеря фокуса (onBlur).Попробуйте самостоятельно реализовать валидацию формы из примера в статье - с приведением типов и проверкой совпадения полей. А затем сделайте то же самое с помощью Valibot.
Если после этого я не смогу вас убедить - тогда, пожалуйста, примите мои извинения за ваше потраченное время.
Правильно ли я понимаю, что вы предлагаете подключить весь Zod (14,33 KB) вместо использования Valibot и tree-shaking? Можете пояснить, почему такой вариант предпочтительнее?
Тот же пример после сборки и tree-shaking:
Кто скажет, что это 2 килобайта - пусть первый бросит в меня камень.
Всё верно. Я намеренно исключил их упоминание из статьи, чтобы сосредоточить внимание читателя на различиях между Zod и Valibot.
Что касается поддержки – базовые сценарии работы валидатора на моем опыте были покрыты на 100%. Однако, безусловно, могут быть edge-кейсы, где другой инструмент окажется более удобным.
Есть подозрение, что с серверными компонентами вы напутали. Выдержка из документации.
There is no directive for Server Components.
A common misunderstanding is that Server Components are denoted by "use server", but there is no directive for Server Components. The "use server" directive is used for Server Functions.
При всем уважении, но зачем вы приплетаете svg сюда и уходите в дебри? Анализируя все ваши "замечания", у меня складывается впечатление что название статьи и вступление полностью проигнорировано.
А если объективно, то вы предлагаете каждому фронтендеру покупать лицензию фотошопа? Более того, статья не про выбор инструмента, чем сжимать и ресайзить фотографии, а в целом о подходе и правилах работы с картинками, на что наличие фотошопа не влияет.
Оригинальное изображение взятое из макета без каких-либо модификаций. К сожалению я не понимаю, какую ценность даст читателю ссылка на картинку, добавить её что бы что?
Таблица служит показателем того, что произошло с весом картинки после ресайза и оптимизации.
Бесконечно с вами согласен, но есть нюанс, доклад был с уклоном на CI (если я не смог донести эту мысль, то извините), по этой причине такие опции как кэш, гит-хуки не упоминались. В целом, если правильно настроить IDE, то запускать локально линтинг не придется, тогда и кэш не будет нужен.
По той же ссылке предоставленной @nin-jin, Дэн пишет что by default они ничего не будут патчить. И в исходном коде react
18.2.0, нет ничего связанного с cache.Точно, есть же еще и terser.
Вьюшки часом не на react? Интересуюсь с целью понять на сколько хорошо работает react-refresh из коробки, немного смущен пометкой "эксперимент".
И за наводку на
loadableтоже спасибо, понадобится.React Testing Library - устраивает более чем, мы на него переехали с enzyme. Изъянов в нем не нашли, даже стало немного приятней тесты писать, но это конечно субъективно.
По поводу vite, до него к сожалению руки еще не дошли. Очень хочу протестировать до конца swc и понять чем придется пожертвовать, если babel отключим. А потом уже esbuild, vite и может еще что-то интересное подвернется.