В приведенной цитате из доки, когда говорится о "static type inference", имеется в виду как раз то, что Вы называете, "преобразование типов в runtime", а не z.infer<typeof userSchema>.
Если на Ваш взгляд это не является необходимым – окей, Ваше право не использовать это. Тогда Вам действительно не нужен zod, Ваша библиотека подходит куда лучше.
Но Вы не правы, если считаете, что не это, а что-то другое, является основной фишкой zod.
Zod is a TypeScript-first schema declaration and validation library. <...> The goal is to eliminate duplicative type declarations. With Zod, you declare a validator once and Zod will automatically infer the static TypeScript type. It's easy to compose simpler types into complex data structures.
То есть основная идея – это то, что парсишь данные и получаешь на выходе корректно типизированные значения. Твоя же библиотека делает только самую простую часть – валидацию.
Классно, что есть такое упрощенное решение, но говорить, что ты сделал тот же zod, но в 10 раз быстрее, как ты описываешь себя в описании, мягко говоря, некорректно.
Если ты зачем-то хочешь тот же zod, но более оптимизированный (как будто в этом основная проблема твоего приложения), то стоит, скорее, смотреть в сторону Valibot. Но и то, это лишнее, жертвуем DX, чтобы сэкономить пару миллисекунд.
Так отображается ли кнопка или какого цвета строка в таблице – это не бизнес-логика, это стейт представления. Он и не должен храниться в сторе, он должен лежать в компоненте.
Это всё старые пердуны (те самые, которые еще MVC придумали) с чего-то решили, что бизнес-логику лучше хранить отдельно от представления. Но вы не обращайте внимания, продолжайте размазывать данные равномерно по всему приложению, как масло по хлебу. Так удобнее 😈
В статье, видимо, забыли указать, что в функции login должна быть еще какая-то общая логика, иначе всё это бессмысленно и проще просто саму функцию вызывать) Т.е., почему бы тогда вместо login('twitter', '123'); сразу не написать loginWithTwitter('123');? Количество символов то же, лишних абстракций меньше.
Если там есть общий код, то тогда есть смысл использовать "стратегию". Они нужны как раз для того, чтобы разбить код на общий и конкретные драйверы, чтобы переиспользовать общий и легко дописывать драйверы без необходимости копаться и что-то добавлять в старый код. Открытость-закрытость и прочие заморочки в действии)
ООП тут, конечно, не нужно, в статье оно просто для понтов, "стратегию" можно реализовать и простым колбэком:
import { login } from './auth';
import { loginWithTwitter, loginWithLocal } from './auth/drivers';
login(loginWithTwitter, '123');
login(loginWithLocal, "bytefer", "666");
Лучшая практика модальных окон – не использовать их ни для чего сложного. Текст, картинки, видео, выбор действия кнопками, маленькая форма – и всё, ничего более. Если нужно что-то сложнее – открываем новую страницу.
Если выбирать топ-3 по сложности элемента на фронте, то это будет:
форма;
таблица;
модальное окно.
Но разве это волнует дизайнера? Давайте навернём многостраничную форму и длинную таблицу с фильтрами и сортировками прямо в модалке, какая разница сколько человеко-часов займет их разработка! 💩
React – это не универсальный молоток, круг его обязанностей очень узок: "react" отвечает за сравнение изменений между рендерами, "react-dom" – за то, чтобы внести эти изменения в DOM, JSX – за HTML-in-JS. Так как "react" требует писать компоненты чистыми, а это почти никогда невозможно на 100%, он также предоставляет хуки, чтобы обходить это ограничение.
Всё остальное – формы, менеджмент состояния и прочее – должно решаться сторонними библиотеками. Это очень сложно и не всегда получается хорошо, но примеры из статьи (типа сравнение форм в React и Svelte) просто притянуты за уши.
Автор, к сожалению, за 10 лет, так и не понял этого. Как и то, что useEffect не имеет прямого отношения к циклу жизни компонента.
Да не, смотрят. Я обычно смотрю на закрепы, там должно быть пару крутых самостоятельных проектов с интересным функционалом и проработанными стилями. Если там есть только один туду на Bootstrap, это значит, что человеку просто неинтересно программировать.
Обычно те, у кого нет ничего на GitHub, это те же люди, которые ноют в LinkedIn, что уже полгода ходят на собесы и не могут найти работу.
Vue.js просто проще. Он хорошо подходит для небольших приложений, но чтобы его правильно масштабировать нужны очень хорошо понимать, что ты делаешь. Поэтому, в основном, всё в кашу превращается
При подключении внешнего стилевого файла CSS отделён от разметки, поэтому его проще поддерживать.
Стили, отделенные от разметки, которой они принадлежат, сложнее поддерживать, потому что, когда ты видишь название класса, ты не знаешь, что именно он стилизует. Ты можешь только догадываться. С переменным успехом, в зависимости оттого, как хорошо у автора с неймингом.
Подключение стилей извне также позволяет использовать препроцессоры, чтобы ускорить процесс разработки и сделать код легко читаемым
Ускорить – возможно. Сделать легкочитаемым – вряд ли.
позволяет всем участникам быстрее ориентироваться в стилях.
То же самое, что я говорил выше, только наоборот. Когда я вижу разметку, по названию класса я, скорее всего, не угадаю, как элемент стилизован (если только класс не называется btn-red).
При использовании внешнего CSS вы видите структуру своего проекта
Ну да, разработчики смотрят на структуру проекта по CSS-файлам. CSS-файлы вынуждают держать компоненты не одним файлом, а папкой, что только усложняет восприятие структуры.
Вы понимаете, где и какие свойства заданы элементу и можете легко их изменить.
... и заодно сломать пол-проекта. По крайней мере, с inline-стилями я уверен, что изменение здесь больше ни на что не повлияет.
Если писать стили внутри атрибута style, то HTML становится трудночитаемым. Логическая структура исчезает и стили размываются по всему коду. Следить за стилизацией становится непросто, а поиск фрагмента, в котором нужно изменить CSS-правило, отнимает немало времени. И чем крупнее проект, тем сложнее управлять стилизацией.
Актуально для проектов, которые не используют фреймворки и компонентный подход. Которых сейчас почти не встретишь. В компонентах, чем ближе стили к верстке, тем проще.
Стили из внешнего CSS файла легко переопределять, так как у каждого селектора своё значение специфичности. Класс приоритетнее селектора тега, а идентификатор приоритетнее класса.
А если писать стили inline, то вообще ничего переопределять не придется)
Во время первой загрузки страницы внешние стили отображаются с задержкой: браузеру нужно время, чтобы скачать стилевой файл.
А мы так хотим увидить страницу до того, как к ней применятся стили! (нет)
Почему всё же не стоит использовать inline-стили
Я не эксперт в вопросе безопасности, поэтому про CSP говорить не буду, уже сказано.
Но что касается самого кода, то inline-стили мы не используем, потому что классы позволяют нам переиспользовать CSS-код и абстрагироваться от низкоуровнего margin-top: 10px и т.д.
Однако, если есть возможность использовать компонентный подход, то лучше такие элементы, как button, выделять в отдельные компоненты и стили прописывать прямо в HTML. И лучше для этого использовать не встроенный атрибут style , так как получается многословно, а библиотеки для атомарного CSS, такие как Tailwind CSS.
Вывод
Аргументы, приведенные в статье, неверны, а выводы уже неактуальны.
Не очень понятна практическая польза сравнения Redux и Vuex. Это как сравнивать, кто сильнее: акула или медведь) У них всё равно разный ареал обитания и заменить один на другой не получится.
В приведенной цитате из доки, когда говорится о "static type inference", имеется в виду как раз то, что Вы называете, "преобразование типов в runtime", а не
z.infer<typeof userSchema>.Если на Ваш взгляд это не является необходимым – окей, Ваше право не использовать это. Тогда Вам действительно не нужен zod, Ваша библиотека подходит куда лучше.
Но Вы не правы, если считаете, что не это, а что-то другое, является основной фишкой zod.
Как в доке описывается zod:
Zod is a TypeScript-first schema declaration and validation library. <...> The goal is to eliminate duplicative type declarations. With Zod, you declare a validator once and Zod will automatically infer the static TypeScript type. It's easy to compose simpler types into complex data structures.
То есть основная идея – это то, что парсишь данные и получаешь на выходе корректно типизированные значения. Твоя же библиотека делает только самую простую часть – валидацию.
Классно, что есть такое упрощенное решение, но говорить, что ты сделал тот же zod, но в 10 раз быстрее, как ты описываешь себя в описании, мягко говоря, некорректно.
Если ты зачем-то хочешь тот же zod, но более оптимизированный (как будто в этом основная проблема твоего приложения), то стоит, скорее, смотреть в сторону Valibot. Но и то, это лишнее, жертвуем DX, чтобы сэкономить пару миллисекунд.
Что-то мне подсказывает, что вы не относитесь ни к первым, ни ко вторым)
А: Я не понимаю, зачем нужен Redux.
Б: Это Model, как Model в MVC.
А: Понял.
Вот так я представлял разговор с "бэкендщиком со стажем".
Так отображается ли кнопка или какого цвета строка в таблице – это не бизнес-логика, это стейт представления. Он и не должен храниться в сторе, он должен лежать в компоненте.
Это всё старые пердуны (те самые, которые еще MVC придумали) с чего-то решили, что бизнес-логику лучше хранить отдельно от представления. Но вы не обращайте внимания, продолжайте размазывать данные равномерно по всему приложению, как масло по хлебу. Так удобнее 😈
Next.js и Universal даже не в одной весовой категории:
Next.js: npm – 3.63 млн скачиваний в неделю, Github – 97.5 тысяч звезд;
Universal: npm – 0.132 млн скачиваний, Github – 3.9 тысячи.
В статье, видимо, забыли указать, что в функции
loginдолжна быть еще какая-то общая логика, иначе всё это бессмысленно и проще просто саму функцию вызывать)Т.е., почему бы тогда вместо
login('twitter', '123');сразу не написатьloginWithTwitter('123');? Количество символов то же, лишних абстракций меньше.Если там есть общий код, то тогда есть смысл использовать "стратегию". Они нужны как раз для того, чтобы разбить код на общий и конкретные драйверы, чтобы переиспользовать общий и легко дописывать драйверы без необходимости копаться и что-то добавлять в старый код. Открытость-закрытость и прочие заморочки в действии)
ООП тут, конечно, не нужно, в статье оно просто для понтов, "стратегию" можно реализовать и простым колбэком:
Лучшая практика модальных окон – не использовать их ни для чего сложного. Текст, картинки, видео, выбор действия кнопками, маленькая форма – и всё, ничего более. Если нужно что-то сложнее – открываем новую страницу.
Если выбирать топ-3 по сложности элемента на фронте, то это будет:
форма;
таблица;
модальное окно.
Но разве это волнует дизайнера? Давайте навернём многостраничную форму и длинную таблицу с фильтрами и сортировками прямо в модалке, какая разница сколько человеко-часов займет их разработка! 💩
Качество перевода, кстати, очень низкое. Как будто Google Translate читаешь.
React – это не универсальный молоток, круг его обязанностей очень узок: "react" отвечает за сравнение изменений между рендерами, "react-dom" – за то, чтобы внести эти изменения в DOM, JSX – за HTML-in-JS. Так как "react" требует писать компоненты чистыми, а это почти никогда невозможно на 100%, он также предоставляет хуки, чтобы обходить это ограничение.
Всё остальное – формы, менеджмент состояния и прочее – должно решаться сторонними библиотеками. Это очень сложно и не всегда получается хорошо, но примеры из статьи (типа сравнение форм в React и Svelte) просто притянуты за уши.
Автор, к сожалению, за 10 лет, так и не понял этого. Как и то, что useEffect не имеет прямого отношения к циклу жизни компонента.
Да не, смотрят. Я обычно смотрю на закрепы, там должно быть пару крутых самостоятельных проектов с интересным функционалом и проработанными стилями. Если там есть только один туду на Bootstrap, это значит, что человеку просто неинтересно программировать.
Обычно те, у кого нет ничего на GitHub, это те же люди, которые ноют в LinkedIn, что уже полгода ходят на собесы и не могут найти работу.
Задавать вопросы, на которые легко отвечает любое IDE, — это та ещё пустая трата времени.
Vue.js просто проще. Он хорошо подходит для небольших приложений, но чтобы его правильно масштабировать нужны очень хорошо понимать, что ты делаешь. Поэтому, в основном, всё в кашу превращается
"Лапша" – это не нормальная эволюция, а одна из следующих причин:
У программистов было мало времени
У программистов было мало опыта в написании масштабируемого кода
Что касается паттернов, то тут понятно, что
водка лучше самогонаобщепринятое решение всегда лучше своего велосипеда.А то, что Angular неидеальный, – это очевидно, хотя бы по 1,7k issue на GitHub
Стили, отделенные от разметки, которой они принадлежат, сложнее поддерживать, потому что, когда ты видишь название класса, ты не знаешь, что именно он стилизует. Ты можешь только догадываться. С переменным успехом, в зависимости оттого, как хорошо у автора с неймингом.
Ускорить – возможно. Сделать легкочитаемым – вряд ли.
То же самое, что я говорил выше, только наоборот. Когда я вижу разметку, по названию класса я, скорее всего, не угадаю, как элемент стилизован (если только класс не называется
btn-red).Ну да, разработчики смотрят на структуру проекта по CSS-файлам. CSS-файлы вынуждают держать компоненты не одним файлом, а папкой, что только усложняет восприятие структуры.
... и заодно сломать пол-проекта. По крайней мере, с inline-стилями я уверен, что изменение здесь больше ни на что не повлияет.
Актуально для проектов, которые не используют фреймворки и компонентный подход. Которых сейчас почти не встретишь. В компонентах, чем ближе стили к верстке, тем проще.
А если писать стили inline, то вообще ничего переопределять не придется)
А мы так хотим увидить страницу до того, как к ней применятся стили! (нет)
Почему всё же не стоит использовать inline-стили
Я не эксперт в вопросе безопасности, поэтому про CSP говорить не буду, уже сказано.
Но что касается самого кода, то inline-стили мы не используем, потому что классы позволяют нам переиспользовать CSS-код и абстрагироваться от низкоуровнего
margin-top: 10pxи т.д.Однако, если есть возможность использовать компонентный подход, то лучше такие элементы, как
button, выделять в отдельные компоненты и стили прописывать прямо в HTML. И лучше для этого использовать не встроенный атрибутstyle, так как получается многословно, а библиотеки для атомарного CSS, такие как Tailwind CSS.Вывод
Аргументы, приведенные в статье, неверны, а выводы уже неактуальны.
Не очень понятна практическая польза сравнения Redux и Vuex. Это как сравнивать, кто сильнее: акула или медведь) У них всё равно разный ареал обитания и заменить один на другой не получится.
Если ограничить ширину, то всё равно будут проблемы.
Другой вариант — сделать невидимый элемент (через HTML или ::after), которые будут дополнять ряд.
Головокружение — меньшая из проблем. Эпилептический припадок — вот это "неприятный" исход недоработанного UX/UI