Да и банально зачем делать запрос и ждать ответ, если клиент и сам может знать, что этого делать нет необходимости.
Single source of truth. Если проверка существует, то ее логику лучше реализвать один раз. Если хочется переиспользовать, то автотматически сконвертировать в JS для веба, но не писать саму логику 2 раза, можно ведь ошибки сделать, расхождения и тд. Поэтому валидация на сервере, а фронт просто отражает результат валидации.
Просто автор совершил открытие что в мире существует не только java и делится с нами своими уникальными и незабываемыми впечатлениями. Я его понимаю, совершив открытие обычно хочется поделиться им с другими.
TS не кинет исключение, ничего не сообщит, если в рантайме прилетят данные совершенно другого типа, а это случиьтся может вообще без проблем.
Если грамотно использовать TS и соблюдать согласованной контракта общения с источниками внешних данных, то рантайме проверки не нужны. Более того рантайм проверки вреды и противореччат концепции TypeScript, который не существуют в рантайме by design и это неплохо. Если и делать где-то рантайм проверки, то при поступлении внешних данных источник которых не поддается контролю (JSON.parse).
Многие работники сферы HR с вами не согласились бы.
Возможно, это дело вкуса. А как считаете вы, что лучше слабая или сильная типизация?
Зависит от проекта. Если проект не одноразовый и сложнее todo app, то TypeScript конечно стоит выбирать изначально и сразу в strict режиме. С ростом проекта и команды преимущества будут ощущаться все сильнее в отличии от JS когда с ростом будут увеличиваться только проблемы.
Однако это так и есть. Имеется ввиду что node.js используется просто как средство автоматизации самых различных задач во фронте. Большинство современных фронтовых тулов, которых тысячи, сделаны на ноде, но работают они как правило локально, без поднятия сервера, то есть это просто скрипты процессы которых чаще всего убиваются после завершения задачи.
Минусы есть. Я очень не люблю когда используются default экспорты, даже иногда просто ненавижу, и многие придерживаются такого же мнения. default экспорты нужно перманентно забанить везде и навсегда.
export const Funcomponent = React.memo(() => {
return <div>Hiya!! I am a Funtional component</div>;
});
Каюсь что статью не читал, только код посмотрел и сразу комментировать, как обычно.
IV обязан храниться в секрете, в то время как соль хэша можно хранить в открытом виде, это не секрет.
Мне казалось что IV не должен повторятся при использовании того же самого ключа (рандом), а хранение в секрете желательно, также как и для key derivation хешей, но не обязательно.
Зависит от проекта. Если проект не одноразовый и сложнее todo app, то TypeScript конечно стоит выбирать изначально и сразу в strict режиме. С ростом проекта и команды преимущества будут ощущаться все сильнее в отличии от JS когда с ростом будут увеличиваться только проблемы.
Эту штуку уже не упоминают в приличном обществе. Также как и Gulp/Grunt, Bower и прочие анахромизмы.
PS Полистайте вакансии лидеров рынка и возьмите киворды оттуда.
Мне казалось что IV не должен повторятся при использовании того же самого ключа (рандом), а хранение в секрете желательно, также как и для key derivation хешей, но не обязательно.