Существует вот такой обширный замер производительности большинства известных библиотек для валидации. Самые быстрые (например typebox) используют кодогенерацию. Насколько я понимаю к $mol он не имеет никакого отношения, кроме схожести названий https://moltar.github.io/typescript-runtime-type-benchmarks/
Самый сложный баг, который мне приходилось чинить, был вызван неправильным закрытием транзакции. Код как бы отсылал "end;" на сервер постгреса, но не дожидался ответа, и из-за некоторой специфики драйвера следующие операторы произвольно попадали внутрь той же транзакции.
И всё бы ничего, но иногда транзакция завершалась с ошибкой и роллбэчилась, и вот тогда происходил сущий кошмар.
Представьте, что вы смотрите на два последовательных успешных update-запроса к базе, которые вообще не связаны с той транзакцией, но при этом первый из запросов никак не изменил данные, а второй изменил.
Я пока этот баг искал успел прочитать код драйверав в поисках ошибки
Да, и в итоге у вас часть тудушек просто отсутствует, потому что кому-то из команды было влом заводить для неё задачу. И вы наблюдаете уменьшение количества тудушек, но не в состоянии сказать, стал ваш код лучше или же просто костыли теперь никак не подсвечены
Пример с вогнутыми и выгнутыми линиями перестаёт работать, когда отсутствует непрерывная (может ещё и дифференцируемая) функция, приводящая вогнутые линии к выгнутым. Но вообще говоря такая функция не обязана существовать. На самом деле таких хороших пространств меньшинство.
И тот факт, что люди способны договориться, косвенно свидетельствует о наличии объективной реальности. Объективной в том смысле, что существует хорошая функция, переводящая наблюдаемые пространства друг в друга. Я могу видеть красный цвет не так, как вы, но я всё ещё могу отличать красный от зелёного. Но почему я могу это делать? Почему большинство людей способны это делать? Если мы наблюдаем случайные субъективные реальности, то большинство людей были бы неспособны понять даже концепцию цвета.
Но раз мы все в состоянии понимать друг друга примерно во всём, то и наши мониторы устроены примерно одинаково
Комментарии людей, которые что-то знают, всегда полезны для читателя статьи. Вам, как автору, может не нравиться критика, но для меня она оказалась полезной. Я могу соединить вашу статью и замечания к ней и получить лучшее приложение, чем я сделал бы без этих замечаний
Эти слова табуировались вовсе не потому, что они связаны с физиологией. В дивном новом мире люди занимаются сексом с кем угодно когда угодно, человек даже не имеет морального права отказываться. Табуировались чувства к другим людям, привязанность. В том числе отношения матери с ребёнком
Чертовски хорошо у вас получилось. Да, в моей версии из-за useEffect компонент будет дважды рендериться. Я по какой-то причине даже не подумал о том, что рендер можно отдельно от компонента определить, не хватило гибкости мышления
Это уже вопрос не render-а, а реконсиляции. Там React находит вместо старого компонента новый. Ввиду чего убивает его и создаёт новый. Отдельно отмечу, что он помимо этого убивает и связанный с ним DOM.
Всё-таки вы не правы, это вопрос рендера. Компонент всегда имеет одинаковый тип Dialog, поэтому размонтирование не происходит. <Dialog /> каждый раз новый, Dialog один и тот же, так и должно быть
Выше уже написали про useMemo, который, конечно, неплохо было бы использовать. Я не хотел написать идеальный код, скорее показать общую идею, которую при желании можно улучшать.
Кажется, вы не правы насчёт того, что я "убиваю" диалог. Он будет каждый раз рендериться, но не монтироваться. Но ведь у реакта по умолчанию именно такое поведение и есть: родитель рендерится -> рендерится потомок.
А как обычно работают с диалогом? Просто я встречал именно те две версии, о которых написал. Обычно есть компонент, который принимает в себя разные пропсы, включая open, и есть отдельно хук, который этим компонентом управляет и наружу выбрасывает setOpen
HOC не позволит менять каррированные пропсы. То есть один раз их вставил в компонент и дальше пользуешься тем что получилось. Но в моём случае hook должен был многократно менять каррированные пропсы
Изначально я решал следующую проблему: у меня был готовый компонент A с большим количеством пропсов, при этом частью этих пропсов props_1 я хотел управлять внутри отдельного хука hook, а часть пропсов props_2 прокидывать в него из другого компонента B. Я также хотел, чтобы компонент B ничего не знал о пропсах props_1.
Вот и выходит, что мой hook должен был принять компонент A, вставить в него свои пропсы props_1, и вернуть наружу в компонент B более простой каррированный компонент.
Полагаю, что это может быть полезно при использовании готовых наборов компонентов вроде бутстрепа, чтобы частично их кастомизировать
Существует вот такой обширный замер производительности большинства известных библиотек для валидации. Самые быстрые (например typebox) используют кодогенерацию. Насколько я понимаю к $mol он не имеет никакого отношения, кроме схожести названий https://moltar.github.io/typescript-runtime-type-benchmarks/
Так же вот тут можно найти ссылку на дипломную работу, в которой описывается создание библиотеки для валидации https://valibot.dev/guides/introduction/
Самый сложный баг, который мне приходилось чинить, был вызван неправильным закрытием транзакции. Код как бы отсылал "end;" на сервер постгреса, но не дожидался ответа, и из-за некоторой специфики драйвера следующие операторы произвольно попадали внутрь той же транзакции.
И всё бы ничего, но иногда транзакция завершалась с ошибкой и роллбэчилась, и вот тогда происходил сущий кошмар.
Представьте, что вы смотрите на два последовательных успешных update-запроса к базе, которые вообще не связаны с той транзакцией, но при этом первый из запросов никак не изменил данные, а второй изменил.
Я пока этот баг искал успел прочитать код драйверав в поисках ошибки
Да, и в итоге у вас часть тудушек просто отсутствует, потому что кому-то из команды было влом заводить для неё задачу. И вы наблюдаете уменьшение количества тудушек, но не в состоянии сказать, стал ваш код лучше или же просто костыли теперь никак не подсвечены
Полноценная демократия, вот и посмотрим
Пример с вогнутыми и выгнутыми линиями перестаёт работать, когда отсутствует непрерывная (может ещё и дифференцируемая) функция, приводящая вогнутые линии к выгнутым. Но вообще говоря такая функция не обязана существовать. На самом деле таких хороших пространств меньшинство.
И тот факт, что люди способны договориться, косвенно свидетельствует о наличии объективной реальности. Объективной в том смысле, что существует хорошая функция, переводящая наблюдаемые пространства друг в друга. Я могу видеть красный цвет не так, как вы, но я всё ещё могу отличать красный от зелёного. Но почему я могу это делать? Почему большинство людей способны это делать? Если мы наблюдаем случайные субъективные реальности, то большинство людей были бы неспособны понять даже концепцию цвета.
Но раз мы все в состоянии понимать друг друга примерно во всём, то и наши мониторы устроены примерно одинаково
Комментарии людей, которые что-то знают, всегда полезны для читателя статьи. Вам, как автору, может не нравиться критика, но для меня она оказалась полезной. Я могу соединить вашу статью и замечания к ней и получить лучшее приложение, чем я сделал бы без этих замечаний
Хорошее видео. Долго не решался свой плагин писать, думал это гораздо сложнее. Наверное, свои подводные камни там есть, буду пробовать
Надо просто играть в шахматы Фишера, где начальная расстановка сильных фигур определяется произвольно
Есть ещё такой лайфхак: type Inc = [1, 2, 3, 4, 5, ...]. Тогда type One = Inc[0], type Two = Inc[1].
Поскольку ограничения на рекурсию довольно жёсткие, такой подход оправдан в целях экономии 'шагов' рекурсии
Эти слова табуировались вовсе не потому, что они связаны с физиологией. В дивном новом мире люди занимаются сексом с кем угодно когда угодно, человек даже не имеет морального права отказываться. Табуировались чувства к другим людям, привязанность. В том числе отношения матери с ребёнком
Чертовски хорошо у вас получилось. Да, в моей версии из-за useEffect компонент будет дважды рендериться. Я по какой-то причине даже не подумал о том, что рендер можно отдельно от компонента определить, не хватило гибкости мышления
Всё-таки вы не правы, это вопрос рендера. Компонент всегда имеет одинаковый тип Dialog, поэтому размонтирование не происходит. <Dialog /> каждый раз новый, Dialog один и тот же, так и должно быть
Выше уже написали про useMemo, который, конечно, неплохо было бы использовать. Я не хотел написать идеальный код, скорее показать общую идею, которую при желании можно улучшать.
Кажется, вы не правы насчёт того, что я "убиваю" диалог. Он будет каждый раз рендериться, но не монтироваться. Но ведь у реакта по умолчанию именно такое поведение и есть: родитель рендерится -> рендерится потомок.
А как обычно работают с диалогом? Просто я встречал именно те две версии, о которых написал. Обычно есть компонент, который принимает в себя разные пропсы, включая open, и есть отдельно хук, который этим компонентом управляет и наружу выбрасывает setOpen
Да, с типами немного сложно.
Вот небольшой пример: https://codesandbox.io/s/eloquent-marco-hqfg1
HOC не позволит менять каррированные пропсы. То есть один раз их вставил в компонент и дальше пользуешься тем что получилось. Но в моём случае hook должен был многократно менять каррированные пропсы
Спасибо за useState! Сколько ни пытался избавиться от классового компонента, так и не смог придумать альтернативы
Изначально я решал следующую проблему: у меня был готовый компонент A с большим количеством пропсов, при этом частью этих пропсов props_1 я хотел управлять внутри отдельного хука hook, а часть пропсов props_2 прокидывать в него из другого компонента B. Я также хотел, чтобы компонент B ничего не знал о пропсах props_1.
Вот и выходит, что мой hook должен был принять компонент A, вставить в него свои пропсы props_1, и вернуть наружу в компонент B более простой каррированный компонент.
Полагаю, что это может быть полезно при использовании готовых наборов компонентов вроде бутстрепа, чтобы частично их кастомизировать