Краткий пересказ статьи: "... React — отстой, но в итоге я не смог удержаться и решил высказаться по полной…" "... с помощью Redux или чего-то аналогичного, но здесь у меня недостаточно опыта для каких-то конкретных предложений."
Дальше можно расходиться. У автора просто недостаточно опыта в Redux, а приведенный пример кода, тоже не смогли осилить в Redux.
Вот не надо про везде. Никто везде не работал. Обычно это везде строится либо на собственном опыте, либо на чьих то рассказах. Во всех остальных случаях есть нормальные коллективы в которых приятно работать с нормальными коллегами, тим лидами и менеджерами. Тут важно еще как себя позиционировать. Пришел ты проект продвигать или по головам ходить.
Как же это близко и лампово)) Но писать кодом это конечно мощно! Тут выше написали про sketchup.
Лет 10 назад его освоил и с тех пор все модели в нем рисую. Т.е. рисую сразу по тем размерам которые нужны мне. В своем городе нашел компанию, которая потом все мои идеи перерисовывает уже в своей специальной распиловочной программе, а там сама расставляет присадки. Плюс кромка бывает тоже разной. Использую в основном 2мм а например при распиле ящиков это нужно учитывать чтобы присадки совпали. Программа распиловщика это все учитывает. Так что это их головная боль, не моя.
Так же можно кучу времени потратить на подгонку к направляющим. Ладно если это просто шариковые 8мм. А если хочется скрытого монтажа, то тут вручную все это предусмотреть может быть не просто. А так фабрика сразу размечает места под будущие крепления, только саморез закрути.
Я полазил по сайту timeweb и не нашел там тарифа среды для разворачивания serverless. Т.е. я так понимаю, был куплен просто VPS и уже на нем была поднята среда для поддержки serverless кода, верно?
Странно почему в 2025 году в выборку не попал Redux-Saga. Конечно возможно потому что порог вхождения в Redux и без того низок, чего уж говорить еще и о Redux-Saga... Но все таки плюсы от саг недооценивать нельзя:
Возможность отмены действий.
Возможность прерывания действий.
Возможность управления списком асинхронных действий.
Представим задачу - дано массив ссылок на картинки, которые нужно загрузить на клиент. Задача сделать так, чтобы одновременно загружалось только 3 картинки. На сагах эта задача решается в несколько строк кода.
Я вообще не понимаю как может ещё существовать React, когда есть $mol! Ведь если это такой крутой фреймворк, то он уже должен был давно вытеснить React с рынка. У него то точно правильная архитектура заложена, не то что у реакта, на котором строить архитектуру не возможно.
Судя по вашему комментарию, пользовательские плейсхолдеры хранятся в самом компоненте, а не в глобальном стопе. Отсюда и все проблемы. Если перенести пользовательские плейсхолдеры в глобальный стор и читать их только там где нужно, точечно выполняя перерендер то это решит проблему.
Как вариант в сторе завести 50 коллекций под каждый тип блока и по уникальному индексу связывать переменные блока (плейсхолдеры) с компонентом.
Когда компонент монтируется, он может вызвать useId() хук который вернёт уникальный ключ текущего компонента, или использовать ключ из базы данных для блока, вы ведь как то их сохраняете.
Ваша статья, яркий пример того, с чем можно столкнуться большое приложение от использования просто React из коробки. Ваше решение похоже на временную меру и суть проблемы не решает. А проблема скорее всего в том что слишком много DOM обновляется на каждый чих.
В вашей ситуации так и просится глобальный стор, который будет хранить все переменные, а эти переменные будут читаться там где надо через специальные компоненты с использованием useSelector. Когда надо обработать событие будет использоваться компонент с вызовом useDispatch, Тем самым получается то, о чем говорят выше - аля использование сигналов только на React.
Выше правильно сказали, в React нет сигналов из коробки. Для этого нужно отдельная зависимость. Redux частично может взять на себя роль сигналов.
Но перевод то не сам себя создал, его же кто-то создал. Обычно когда в переводе находят ошибки, то делают сноски или добавляют комментарии от автора в которых указано, что тут опечатка или автор оригинала вводит в заблуждение.
Программирование на GPU - это отдельный мир программирования. Тут столько нужно знать нюансов, чтобы получить максимальную эффективность. Из того что помню, когда работал с CUDA, так это то что читать матрицу по вертикали было куда медленней, чем читать по горизонтали. Помню я не сразу понял, что причина была в кеше, и то как кешируются данные из глобальной памяти. В вашем алгоритме тоже есть что улучшить, возможно. Попробуйте завести локальные переменные под глобальные переменные (переменная A[m * N + k]), чтобы не читать дважды одно и то же значение.
Насчет скорости вычислений для 7600х7600, я бы начал сравнивать с эталонной программой - простое сложение двух матриц такого же размера. Эта программа на столько просто что там сложно допустить какую то ошибку и она наиболее результативно показывает максимум который достижим для данной размерности. Понаблюдать, за разницей сложения матриц по вертикали и по горизонтали.
На самом деле проблемы оффсетной пагинации куда глобальнее чем кажутся на первый взгляд. Предположим мы уже отфильтровали данные и показали их клиенту. Пока клиент смотри на эти данные были добавлены новые записи в первую страницу. Тогда произойдет сдвиг данных и на второй странице возможно окажутся те же записи, что были и на первой. А если на UI стороне отображение реализовано в виде авто подгрузке по доскролу то клиент увидит задвоение некоторых данных. Курсорная пагинация не обладает подобной проблемой. Новые записи которые были добавлены на первую страницу вообще не попадут в выдачу клиента, до обновления первой страницы.
В одном из проектов как раз реализовывал подобную курсорную пагинацию правда она там была в обе стороны. Обычно при долгой прокрутке страницы, с доскролом, на странице начнет отображаться так много записей что сама страница начнет тормозить и подлагивать. Чтобы этого избежать курсорная подгрузка реализована в обе стороны: при подгрузке третей и более страницы верхние данные удаляются. И наоборот. При прокрутке на верх подгружаются записи которые были удалены ранее, а снизу записи стираются.
А как сделано у вас. Курсоры в обе стороны или только в одну?
Статья о том, что автор не внимательно читал документацию. Но потом автор прочитал документацию и узнал о stopPropagation(). Могу порекомендовать написать статью о preventDefault() и stopImmediatePropagation().
Это аы еще прикрепленный матераил не проверяли. Сейчас не проверял, но раньше было, что если я загружу фотографию, а потом удалю, то по прямой ссылке на сам файл она так и останется на веки лежать в хранилище VK.
Вот прям со всеми пунктами согласен полностью!
Краткий пересказ статьи:
"... React — отстой, но в итоге я не смог удержаться и решил высказаться по полной…"
"... с помощью Redux или чего-то аналогичного, но здесь у меня недостаточно опыта для каких-то конкретных предложений."
Дальше можно расходиться. У автора просто недостаточно опыта в Redux, а приведенный пример кода, тоже не смогли осилить в Redux.
Цитаты по Хабр:
Вот не надо про везде. Никто везде не работал. Обычно это везде строится либо на собственном опыте, либо на чьих то рассказах. Во всех остальных случаях есть нормальные коллективы в которых приятно работать с нормальными коллегами, тим лидами и менеджерами. Тут важно еще как себя позиционировать. Пришел ты проект продвигать или по головам ходить.
Как же это близко и лампово)) Но писать кодом это конечно мощно! Тут выше написали про sketchup.
Лет 10 назад его освоил и с тех пор все модели в нем рисую. Т.е. рисую сразу по тем размерам которые нужны мне. В своем городе нашел компанию, которая потом все мои идеи перерисовывает уже в своей специальной распиловочной программе, а там сама расставляет присадки. Плюс кромка бывает тоже разной. Использую в основном 2мм а например при распиле ящиков это нужно учитывать чтобы присадки совпали. Программа распиловщика это все учитывает. Так что это их головная боль, не моя.
Так же можно кучу времени потратить на подгонку к направляющим. Ладно если это просто шариковые 8мм. А если хочется скрытого монтажа, то тут вручную все это предусмотреть может быть не просто. А так фабрика сразу размечает места под будущие крепления, только саморез закрути.
Я полазил по сайту timeweb и не нашел там тарифа среды для разворачивания serverless. Т.е. я так понимаю, был куплен просто VPS и уже на нем была поднята среда для поддержки serverless кода, верно?
Я ни разу не эксперт в RPI, но могу предположить что ответ зависит от того как часто на нее писать.
Облако спустилось на землю.
Пост какого хвастовства, где 90% - вот смотрите какой я молодец, а 10% - "могло быть и лучше".
Я бы озаглавил пост: "Мне было лень разбираться в нейминге переменных и базах данных...".
Ожидал увидеть раздел: "Что пошло не по плану".
Вот только пруфы не завезли, а так да, самый неудачный state management.
Я пользуюсь Redux в 2025. Как и еще те, кто делают более четырех миллионов скачиваний в неделю. Пруфы тут https://www.npmjs.com/package/@reduxjs/toolkit
Ну раз "все забыли", значит больше вопросов нет.
Странно почему в 2025 году в выборку не попал Redux-Saga. Конечно возможно потому что порог вхождения в Redux и без того низок, чего уж говорить еще и о Redux-Saga... Но все таки плюсы от саг недооценивать нельзя:
Возможность отмены действий.
Возможность прерывания действий.
Возможность управления списком асинхронных действий.
Представим задачу - дано массив ссылок на картинки, которые нужно загрузить на клиент. Задача сделать так, чтобы одновременно загружалось только 3 картинки. На сагах эта задача решается в несколько строк кода.
Я вообще не понимаю как может ещё существовать React, когда есть $mol! Ведь если это такой крутой фреймворк, то он уже должен был давно вытеснить React с рынка. У него то точно правильная архитектура заложена, не то что у реакта, на котором строить архитектуру не возможно.
Судя по вашему комментарию, пользовательские плейсхолдеры хранятся в самом компоненте, а не в глобальном стопе. Отсюда и все проблемы. Если перенести пользовательские плейсхолдеры в глобальный стор и читать их только там где нужно, точечно выполняя перерендер то это решит проблему.
Как вариант в сторе завести 50 коллекций под каждый тип блока и по уникальному индексу связывать переменные блока (плейсхолдеры) с компонентом.
Когда компонент монтируется, он может вызвать useId() хук который вернёт уникальный ключ текущего компонента, или использовать ключ из базы данных для блока, вы ведь как то их сохраняете.
Ваша статья, яркий пример того, с чем можно столкнуться большое приложение от использования просто React из коробки. Ваше решение похоже на временную меру и суть проблемы не решает. А проблема скорее всего в том что слишком много DOM обновляется на каждый чих.
В вашей ситуации так и просится глобальный стор, который будет хранить все переменные, а эти переменные будут читаться там где надо через специальные компоненты с использованием useSelector. Когда надо обработать событие будет использоваться компонент с вызовом useDispatch, Тем самым получается то, о чем говорят выше - аля использование сигналов только на React.
Выше правильно сказали, в React нет сигналов из коробки. Для этого нужно отдельная зависимость. Redux частично может взять на себя роль сигналов.
Но перевод то не сам себя создал, его же кто-то создал. Обычно когда в переводе находят ошибки, то делают сноски или добавляют комментарии от автора в которых указано, что тут опечатка или автор оригинала вводит в заблуждение.
Программирование на GPU - это отдельный мир программирования. Тут столько нужно знать нюансов, чтобы получить максимальную эффективность. Из того что помню, когда работал с CUDA, так это то что читать матрицу по вертикали было куда медленней, чем читать по горизонтали. Помню я не сразу понял, что причина была в кеше, и то как кешируются данные из глобальной памяти. В вашем алгоритме тоже есть что улучшить, возможно. Попробуйте завести локальные переменные под глобальные переменные (переменная A[m * N + k]), чтобы не читать дважды одно и то же значение.
Насчет скорости вычислений для 7600х7600, я бы начал сравнивать с эталонной программой - простое сложение двух матриц такого же размера. Эта программа на столько просто что там сложно допустить какую то ошибку и она наиболее результативно показывает максимум который достижим для данной размерности. Понаблюдать, за разницей сложения матриц по вертикали и по горизонтали.
На самом деле проблемы оффсетной пагинации куда глобальнее чем кажутся на первый взгляд. Предположим мы уже отфильтровали данные и показали их клиенту. Пока клиент смотри на эти данные были добавлены новые записи в первую страницу. Тогда произойдет сдвиг данных и на второй странице возможно окажутся те же записи, что были и на первой. А если на UI стороне отображение реализовано в виде авто подгрузке по доскролу то клиент увидит задвоение некоторых данных. Курсорная пагинация не обладает подобной проблемой. Новые записи которые были добавлены на первую страницу вообще не попадут в выдачу клиента, до обновления первой страницы.
В одном из проектов как раз реализовывал подобную курсорную пагинацию правда она там была в обе стороны. Обычно при долгой прокрутке страницы, с доскролом, на странице начнет отображаться так много записей что сама страница начнет тормозить и подлагивать. Чтобы этого избежать курсорная подгрузка реализована в обе стороны: при подгрузке третей и более страницы верхние данные удаляются. И наоборот. При прокрутке на верх подгружаются записи которые были удалены ранее, а снизу записи стираются.
А как сделано у вас. Курсоры в обе стороны или только в одну?
А я то как рад - самого автора $mol-а развеселил. А за умника, спасибо!
Статья о том, что автор не внимательно читал документацию. Но потом автор прочитал документацию и узнал о stopPropagation(). Могу порекомендовать написать статью о preventDefault() и stopImmediatePropagation().
Это аы еще прикрепленный матераил не проверяли. Сейчас не проверял, но раньше было, что если я загружу фотографию, а потом удалю, то по прямой ссылке на сам файл она так и останется на веки лежать в хранилище VK.