У меня просто раньше на старой работе был обычный компьютерный стол (без выреза) и работал я тогда за ноутбуком. Поскольку у ноутбука фиксированное расстояние от клавиатуры до монитора, то, чтобы отодвинуть монитор подальше, нужно отодвинуть весь ноутбук. Это привело к тому что локти оказались на столе. Ну лежат себе локти на столе и лежат, что тут такого, правда?

Спустя время начал левый локоть у меня болеть. Прям больно было класть на стол. А на самом конце локтя образовался какой-то висячий комок. Причем прилично он так висел, как будто там какая-то жидкость скопилась. Пошел к врачу. Врач сразу сказал что у меня бурсит - болезнь дальнобойщиков. Как я понял, у них тоже локоть может постоянно лежать на опоре. Как мне тогда объяснили, физиологически, правильно когда конец локтя все таки не лежит на столе, а рука опирается на стол предплечьем.

Вообще лежащий на столе локоть может приводить еще к сдавливанию локтевого нерва. Из-за этого может быть онемение мизинца и безымянного пальца, слабость в кисти. Лежащий на столе локоть может приводить к ограничению кровообращения.

Проходило все это долго. Наверно месяца полтора или два. На стол класть локоть уже было просто не возможно, так как болевой синдром сразу давал о себе знать. Пришлось двигать ноутбук ближе к краю стола и следить чтобы локоть не лежал на столешнице.

Позже я счел, что наверно занес инфекцию через кожу, так как мое рабочее место было возле окна, окно на первом этаже, рядом с асфальтированной улицей и в добавок мы его часто открывали, чтобы проветривать офис. Отсюда пыль летела из окна и падала на стол. После этого случая я начал раз в неделю протирать стол от пыли.

Вот такая вот история у меня была с локтями и столом. Берегите себя!

Дальше можно расходиться. У автора просто недостаточно опыта в Redux, а приведенный пример кода, тоже не смогли осилить в Redux.

"Хабр уже не тот"

Лет 10 назад его освоил и с тех пор все модели в нем рисую. Т.е. рисую сразу по тем размерам которые нужны мне. В своем городе нашел компанию, которая потом все мои идеи перерисовывает уже в своей специальной распиловочной программе, а там сама расставляет присадки. Плюс кромка бывает тоже разной. Использую в основном 2мм а например при распиле ящиков это нужно учитывать чтобы присадки совпали. Программа распиловщика это все учитывает. Так что это их головная боль, не моя.

Так же можно кучу времени потратить на подгонку к направляющим. Ладно если это просто шариковые 8мм. А если хочется скрытого монтажа, то тут вручную все это предусмотреть может быть не просто. А так фабрика сразу размечает места под будущие крепления, только саморез закрути.

Я бы озаглавил пост: "Мне было лень разбираться в нейминге переменных и базах данных...".

Ожидал увидеть раздел: "Что пошло не по плану".

Redux saga - самый неудачный state management.

Вот только пруфы не завезли, а так да, самый неудачный state management.

Вообще удивляет, кто ещё пользуется Redux в 2025?

Я пользуюсь Redux в 2025. Как и еще те, кто делают более четырех миллионов скачиваний в неделю. Пруфы тут https://www.npmjs.com/package/@reduxjs/toolkit

Пару лет назад уже про него все забыли.

Ну раз "все забыли", значит больше вопросов нет.

• Возможность отмены действий.

• Возможность прерывания действий.

• Возможность управления списком асинхронных действий.

Представим задачу - дано массив ссылок на картинки, которые нужно загрузить на клиент. Задача сделать так, чтобы одновременно загружалось только 3 картинки. На сагах эта задача решается в несколько строк кода.

Как вариант в сторе завести 50 коллекций под каждый тип блока и по уникальному индексу связывать переменные блока (плейсхолдеры) с компонентом.

Когда компонент монтируется, он может вызвать useId() хук который вернёт уникальный ключ текущего компонента, или использовать ключ из базы данных для блока, вы ведь как то их сохраняете.

В вашей ситуации так и просится глобальный стор, который будет хранить все переменные, а эти переменные будут читаться там где надо через специальные компоненты с использованием useSelector. Когда надо обработать событие будет использоваться компонент с вызовом useDispatch, Тем самым получается то, о чем говорят выше - аля использование сигналов только на React.

Выше правильно сказали, в React нет сигналов из коробки. Для этого нужно отдельная зависимость. Redux частично может взять на себя роль сигналов.

Насчет скорости вычислений для 7600х7600, я бы начал сравнивать с эталонной программой - простое сложение двух матриц такого же размера. Эта программа на столько просто что там сложно допустить какую то ошибку и она наиболее результативно показывает максимум который достижим для данной размерности. Понаблюдать, за разницей сложения матриц по вертикали и по горизонтали.

В одном из проектов как раз реализовывал подобную курсорную пагинацию правда она там была в обе стороны. Обычно при долгой прокрутке страницы, с доскролом, на странице начнет отображаться так много записей что сама страница начнет тормозить и подлагивать. Чтобы этого избежать курсорная подгрузка реализована в обе стороны: при подгрузке третей и более страницы верхние данные удаляются. И наоборот. При прокрутке на верх подгружаются записи которые были удалены ранее, а снизу записи стираются.

А как сделано у вас. Курсоры в обе стороны или только в одну?