Насчет недостаточного расстояния до монитора согласен. Но вот насчет провисания локтей и полезности того что они лежат на столе, тема не до конца раскрыта.
У меня просто раньше на старой работе был обычный компьютерный стол (без выреза) и работал я тогда за ноутбуком. Поскольку у ноутбука фиксированное расстояние от клавиатуры до монитора, то, чтобы отодвинуть монитор подальше, нужно отодвинуть весь ноутбук. Это привело к тому что локти оказались на столе. Ну лежат себе локти на столе и лежат, что тут такого, правда?
Спустя время начал левый локоть у меня болеть. Прям больно было класть на стол. А на самом конце локтя образовался какой-то висячий комок. Причем прилично он так висел, как будто там какая-то жидкость скопилась. Пошел к врачу. Врач сразу сказал что у меня бурсит - болезнь дальнобойщиков. Как я понял, у них тоже локоть может постоянно лежать на опоре. Как мне тогда объяснили, физиологически, правильно когда конец локтя все таки не лежит на столе, а рука опирается на стол предплечьем.
Вообще лежащий на столе локоть может приводить еще к сдавливанию локтевого нерва. Из-за этого может быть онемение мизинца и безымянного пальца, слабость в кисти. Лежащий на столе локоть может приводить к ограничению кровообращения.
Проходило все это долго. Наверно месяца полтора или два. На стол класть локоть уже было просто не возможно, так как болевой синдром сразу давал о себе знать. Пришлось двигать ноутбук ближе к краю стола и следить чтобы локоть не лежал на столешнице.
Позже я счел, что наверно занес инфекцию через кожу, так как мое рабочее место было возле окна, окно на первом этаже, рядом с асфальтированной улицей и в добавок мы его часто открывали, чтобы проветривать офис. Отсюда пыль летела из окна и падала на стол. После этого случая я начал раз в неделю протирать стол от пыли.
Вот такая вот история у меня была с локтями и столом. Берегите себя!
Краткий пересказ статьи: "... 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().
Насчет недостаточного расстояния до монитора согласен. Но вот насчет провисания локтей и полезности того что они лежат на столе, тема не до конца раскрыта.
У меня просто раньше на старой работе был обычный компьютерный стол (без выреза) и работал я тогда за ноутбуком. Поскольку у ноутбука фиксированное расстояние от клавиатуры до монитора, то, чтобы отодвинуть монитор подальше, нужно отодвинуть весь ноутбук. Это привело к тому что локти оказались на столе. Ну лежат себе локти на столе и лежат, что тут такого, правда?
Спустя время начал левый локоть у меня болеть. Прям больно было класть на стол. А на самом конце локтя образовался какой-то висячий комок. Причем прилично он так висел, как будто там какая-то жидкость скопилась. Пошел к врачу. Врач сразу сказал что у меня бурсит - болезнь дальнобойщиков. Как я понял, у них тоже локоть может постоянно лежать на опоре. Как мне тогда объяснили, физиологически, правильно когда конец локтя все таки не лежит на столе, а рука опирается на стол предплечьем.
Вообще лежащий на столе локоть может приводить еще к сдавливанию локтевого нерва. Из-за этого может быть онемение мизинца и безымянного пальца, слабость в кисти. Лежащий на столе локоть может приводить к ограничению кровообращения.
Проходило все это долго. Наверно месяца полтора или два. На стол класть локоть уже было просто не возможно, так как болевой синдром сразу давал о себе знать. Пришлось двигать ноутбук ближе к краю стола и следить чтобы локоть не лежал на столешнице.
Позже я счел, что наверно занес инфекцию через кожу, так как мое рабочее место было возле окна, окно на первом этаже, рядом с асфальтированной улицей и в добавок мы его часто открывали, чтобы проветривать офис. Отсюда пыль летела из окна и падала на стол. После этого случая я начал раз в неделю протирать стол от пыли.
Вот такая вот история у меня была с локтями и столом. Берегите себя!
Вот прям со всеми пунктами согласен полностью!
Краткий пересказ статьи:
"... 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().