Стало интересно, а если мы рисуем спрайт на координатах (800, 450), с размерами 50х50, получается, что всё изображения будет невидимо (кроме одного пикселя?), в таком случается отрисовка всё равно происходит полностью? Или в canvas'е есть какие-то оптимизации на этот счёт? Поменяются ли в таком случае результаты замеров?
Не соглашусь, если разработчик впервые видит код с использованием effector'а, то не поймет для чего нужны импортируемые функции из этой библиотеки без прочтения документации. В особенности из-за ввода дополнительный 4-ых сущностей, тот же mobx обходился одной функцией makeAutoObservable. Порог входа ниже чем в redux, но всё ещё заметный.
Мы пришли к ипользованию zustand, количество бойлерплей кода стремится к нулю, для подключения нужно импортировать одну функцию, а на десерт - возможность подключить Redux DevTools. И размер всего в несколько килобайт тоже подкупает.
Если верить npm trends, люди всё больше используют zustand, до redux, конечно, всё ещё очень далеко, но другие варианты уже обогнал.
В случае useState и других хуков React, вы точно знаете в каком порядке идут переменные при деструктуризации, а в случае кастомных хуков вам нужно помнить или каждый раз ходить в хук смотреть в каком порядке возвращаются данные. И ладно если их два, но ведь бывают ситуации когда их сильно больше.
Объект же даёт вам подсказку в ИДЕ и избавляет от необходимости вешать запятые в воздухе.
По поводу использования повторяющихся ссылок, есть интересная статья на эту тему. В таком случае и ссылка будет одна, и при фокусе на неё озвучиться только название, а не весь контент который там потенциально может быть.
Причина заключается в том, что это не стандарт языка, а нечто, что привносит TypeScript в рантайм, в отличие от остальной типизации, которая просто удаляется во время траспиляции. И как и в случае с декораторами, когда данная конструкция появится в JavaScript, она может сильно отличаться от текущей реализации. Возможно если бы enum'ы были за экспериментальным флагом как и декораторы, больше людей обращало бы на это внимания.
В документации TS есть аргумент в пользу объектов как раз из-за совместимости.
Все переводу по одному языку хранятся в одном файле? Для больших сайтов эти JSON файлы будут чересчур большими. i18next поддерживает namespace'ы, что позволяет разделить переводы по страницам/компонентам и подгружать только нужные.
А сервисы, которые помогают с переводами, и правда есть, например, раз и два.
Стало интересно, а если мы рисуем спрайт на координатах (800, 450), с размерами 50х50, получается, что всё изображения будет невидимо (кроме одного пикселя?), в таком случается отрисовка всё равно происходит полностью? Или в canvas'е есть какие-то оптимизации на этот счёт? Поменяются ли в таком случае результаты замеров?
Не соглашусь, если разработчик впервые видит код с использованием effector'а, то не поймет для чего нужны импортируемые функции из этой библиотеки без прочтения документации. В особенности из-за ввода дополнительный 4-ых сущностей, тот же mobx обходился одной функцией makeAutoObservable. Порог входа ниже чем в redux, но всё ещё заметный.
Мы пришли к ипользованию zustand, количество бойлерплей кода стремится к нулю, для подключения нужно импортировать одну функцию, а на десерт - возможность подключить Redux DevTools. И размер всего в несколько килобайт тоже подкупает.
Если верить npm trends, люди всё больше используют zustand, до redux, конечно, всё ещё очень далеко, но другие варианты уже обогнал.
В случае useState и других хуков React, вы точно знаете в каком порядке идут переменные при деструктуризации, а в случае кастомных хуков вам нужно помнить или каждый раз ходить в хук смотреть в каком порядке возвращаются данные. И ладно если их два, но ведь бывают ситуации когда их сильно больше.
Объект же даёт вам подсказку в ИДЕ и избавляет от необходимости вешать запятые в воздухе.
По поводу использования повторяющихся ссылок, есть интересная статья на эту тему. В таком случае и ссылка будет одна, и при фокусе на неё озвучиться только название, а не весь контент который там потенциально может быть.
Причина заключается в том, что это не стандарт языка, а нечто, что привносит TypeScript в рантайм, в отличие от остальной типизации, которая просто удаляется во время траспиляции. И как и в случае с декораторами, когда данная конструкция появится в JavaScript, она может сильно отличаться от текущей реализации. Возможно если бы enum'ы были за экспериментальным флагом как и декораторы, больше людей обращало бы на это внимания.
В документации TS есть аргумент в пользу объектов как раз из-за совместимости.
Все переводу по одному языку хранятся в одном файле? Для больших сайтов эти JSON файлы будут чересчур большими. i18next поддерживает namespace'ы, что позволяет разделить переводы по страницам/компонентам и подгружать только нужные.
А сервисы, которые помогают с переводами, и правда есть, например, раз и два.
Кажется этот момент уже предусмотрели через multi-select, ссылка, хотя без JS и не обошлось.
А компонент, который будет делать API-запросы, если честно пугает.