От вас требовали вовлеченности в процесс сотрудников, но руководство видимо не поняло что вовлеченность в процесс зависит прежде всего от них самих. Это ТОПам нужны психологи, если они не понимают почему их сотрудники не вовлечены в процесс. Но менять себя сложнее, гораздо проще кого то нанять чтобы он решил все их проблема и переделал не вовлеченных сотрудников.
Выявление данного аспекта и преподнесение руководству решения на блюдечке с голубой каёмочкой не дали результатов.
Если перефразировать вашу цитату то получается так: "Я не справился с этой задачей"
Я считаю что уровень компетенции психолога прямо зависит от того каким образом он может донести информацию и изменить пациента. Вы не приводите подробного описания блюдечка с голубой каёмочкой, но видимо руководство увидело совсем не это. Что ж, значит вашей компетенции было недостаточно чтобы что-то поменять.
Но! Вы получили ценный урок! И ценный опыт, над которым можно подумать, понять где были сделаны ошибки, исправить их и попробовать снова новый улучшенный подход.
Вау! Реально круто. Я как раз столкнулся с тем что в глобальном сторе неудобно хранить данные которые все равно сильно привязаны к вьюшке. В вашем случае получается вообще все по красоте получается, если прокидывать прямо компонент через контекст. Реально потом подумаю как потом переделать под такую модель.
Я тоже с вами согласен что глобальный стор нужно использовать на минималках, но когда я начинал все это делать хуков еще и в зачатках не было, поэтому мы выживали как могли.
Вот кстати именно потому по тому что мне нужно было контролировать анимацию, и кол-во отображаемых алертов, я сделал в точности как вы и описали. Наверно только отличие что у меня сами алерты завязаны на сторе а у вас как я понял на событиях. Но сама суть одна и таже.
У меня была жесткая задача: 40 алертов а их надо по очереди показать, какие то алерты с возможностью выбора сценария, какие то сами схлопываются спустя время, а какие то при повторном вызове должне закрывать предыдущий. С помощью стора для алертов очень просто удалось это все порешать.
на верхнем уровне приложения есть HoC, который wrap-ает древо context-ом, в котором есть императивный метод showError(msg: ReactNode | Component, isFixed?: boolean): Promise (и другие методы).
Абсолютно согласен с вашим решением. Если нужно чтобы алерты были частью тудушки, тогда ваше решение самое лучше. В моем случае пришлось бы вешать событие на анмаунт тудушки, а в алерте подписываться на это событие чтобы не пропустить удаление.
Но вот если у нас на экране два списка туду, порталы для алертов при рендере в боди наверно будут работать не так как ожидается: возможно один алерт будет висеть поверх другого. Так что здесь все зависит от задачи и целей которых нужно достигнуть.
Давайте рассмотрим сценарий побольше, нежели валидация инпута. Например, имеется список запланированных дел (типичная тудушка), у каждого запланированного действия есть кнопка «удалить», которая вызывает попап, который спрашивает «уверены ли вы, что хотите удалить запланированное действие».
Возможно у вас компонент алерты засунут внуть тудушки?
В своем проекте я делал алерты которые монтируются как отдельный компонент глобально почти что в самый root компонент. У алертов есть свой стор. Как только в этот стор тудушка кладет алерт он сразу отображается (алерты кстати точь в точь как вы и сказали сделаны: popout: { type, data }).
Я так сделал из принципа DRY — потому что вызвать алерт может не только тудушка.
В моей реализации компонент алерта общается с компонентом тудушки через стор (как вы сказали проброс пропсов сверху), но вот возникла задача как через стор прокидывать события из попапа обратно в компонент? (например событие удаления)
И здесь я решил остановится на варианте что в самих алертах уже буду запускать удаление. Удаление обновит стор и значит обновит тудушку.
У меня камень i5 2012 года выпуска и чтобы серфить интернет и запускать рабочие программы хватает с избытком. А теперь приходят ребята из винды и говорят что у тебя камешик то староват, иди в магазин да и бери ка себе новый камень. Только вот сокет поменялся, тогда и мать себе обнови. Что там у тебя dd3, не ну это совсем старье, сейчас ddX в моде. Ну блок питания можешь старый оставить, хотя не факт что разъемы совпадут.
Погодите, ну у меня комп так то нормальный?
Ну так нормальный он или не нормальный это твои проблемы, а через 3 года поддержка десяточки прикратиться.
Но я же всего то хотел обновить винду на 11
Получается, что ребята из винды своими действиями говорят: да мы знаем, что у тебя комп норм, на ближайшие 10 лет поводов для обновления в виде увеличения скорости проца не предвидеться, а нам и нашим коллегам которые делают процы кушать хочется, поэтому иди и выкидывай на помойку свое старое железо. И нам все равно что это засоряет планету, мы же тебе прямо об этом не скажем. Мы лишь выпустим новый проц с новым чипом.
А я... А я... А я тогда ухожу с линуксом жить. Вот!
Вот уж не думал что все зайдет так далеко и идея с елочкой даст свои плоды. Почти год назад я в скетчапе накидал макет и теперь даже как то не вериться увидеть почти один в один его реализацию.
Почитайте мою последнюю статью здесь на хабре, я там описал проблемы со скролом и то как их решал.
№1. Проверка возврата скролла:
Скролю до 300го комментария, визуально запоминаю позицию скролла и смещение контента.
Нажимаю на рубрику в меню (All streams)
Нажимаю на кнопку вернуться назад
Итог: скрол не вернулся в то место на котором был.
№2 При обновлении страницы скролл возвращается не в том место в котором был
Вообще если бы я бы решал эту проблему, то я бы по другому бы все сделал. Поскольку я так понимаю у вас задача показать все комментарии на первом экране, то я бы начал с того что облегчил бы верстку по максимуму. SVG и картинки из первого показа должны быть убраны. Я бы так же убрал заглушки для картинок - они тоже жрут ресурсы. Блок под комментарием тоже бы скрыл но оставил бы под него место, поскольку он фикс-высота то его можно и потом через js показать. Ну и посмотрел бы насколько бы быстро загружалась бы подобная страница с такими комментариями, если скажим их 1000 штук. Собственно эта страница была бы эталоном скорости, максимум который можно получить. Т.е. эталон вообще не использует JS: только css и html.
Ну а после того как был показан первый экран, уже можно интерактивные элементы развешивать по DOM. Опять же зачем показывать картинку если я до нее не доскролил? Можно и не показывать. Даже интерактивные кнопки под комментарием можно рендерить только тогда когда они в видемой зоне скролла окажутся. Опять же тут проблема гидрации начинает подтягиваться все равно, и здесь в любом случае подвисание всего и вся если гидрировать все и сразу. А делать гидрацию только видимой обласит наверно сложно. Незнаю на сколько подходит для этих задач Vue js, к сожелению не разу его так и не попробовал, зато могу сказать про React. Ну собственно те проблемы что вы описали с перерендером всех комментариев при обновлении рейтинга я в tolstoycomments тоже испытал и на React. Я тоже эксперементировал с кол-во комментариев на страницы и адекватной скоростью их рендера. В итоге я пришел к выводу что больше 130 каментов на странице не показываю. Т.е. прокрутка вверх/вних скрывать каменты снизу/сверху. Конечно у нас виджет и подход немного другой. Проблема с восстановлением скролла решена частично. Проблемы с прокруткой скролла и смещенеим тоже решена частично. Олаживать работу скролла эта конечно очень не простое занятие.
По React могу сказать что как только я отказался от классовых компонентов и переписал все на чистые функции, скорость заметно выпросла. Конечно я думаю что я просто в первый раз код был написан просто не очень удачно и в этом была проблема:) Ну и да, нужно следить за тем чтобы не делать лишних рендеров если по факту ничего в компоненте не поменялось.
Жалко что вы не выложили готовый результат куда-нибудь чтобы можно было сразу его потыкать. Ок, выполняем магическую комбинацию из команд:
git clone https://gitlab.com/agratoth/nextjs-rxjs-alerting-service.git
cd .\nextjs-rxjs-alerting-service\
npm i
npm run build
npm run start
На самом деле ваш скрипт можно доработать, а именно если сообщений слишком много то сделать так чтобы они не все сразу показывались, а отображались пачками, например в одно время у ВК был придел 3 сообщения. А потом остальные показывались только когда появлялось свободное место, т.е. когда одно из 3х сообщений закрывалось. Некий аналог стека. Думаю с помощью RxJs это было бы особенно эффектно реализовать.
Ну и верстка может ехать при определенных размерах страницы на мобиле. Конечно это демка, но если кто-то вашу реализацию будет брать в продакшен, верстку нужно будет править.
Да, вы правы, проблема в том что я не знаю финального scrollHeight. А узнать его можно только после того как компоненты с изменяемой высотой будут отрендерены на странице. По сути scrollHeight можно узнать после вызова события onRenderChildrenComplete
И да, я должен снять перед вами шляпу, потому что как то давно еще видел у вас как раз реализацию с динамическим скролом, который автоматически подгружал нужные данные в нужном положении скролла (кажется это был некий grid). Собственно по аналогии как это было реализовано у вас я и реализовал это в своем текущем проекте.
В моем случае .Where(n => n.Items.Count() == 0)работало шустрее в разы. Да и в дальнейшем я понял что лучше в LINQ Any вообще не использовать и делать все на Count. К сожалению пока нет возможности сделать ToString обоих запросов.
MSSQL и EF это отдельный, уникальный и дивный мир! Я в вебе с тех самых времен, когда верстали еще под IE6, и навыки верстака оценивались знаниями как выравнить блочный элемент по центру, как сделать прозрачность или как не словить баг с margin.
Прошло 15 лет и ничего не поменялось. Я по прежнему занимаюсь шаманством. Переписываю запрос LINQ c `.where(n => n.PropABool && !n.PropBBool)` на `.where(n => n.PropABool == true && n.PropBBool == false)`
Запрос вроде вашего `.Where(x => x.DisplayName.StartsWith(key))` это вообще не позволительная роскош! Нет, тут только полнотекстовый поиск, там все норм со скоростью работы, а обычный like использовать на больших полях опасно!
Вот еще такой пример: `.Where(n => !n.Items.Any())` или `.Where(n => n.Items.Count() == 0)`. Вопрос к знатокам, какой будет работать шустрее?
Здесь все зависит от личного опыта. В текущем проекте и так уже подключена стандартная библиотека управления AccelStepper. Для текущего проекта ее вполне достаточно. Добавить обработку концевика - это еще несколько ифов в программе.
Думаю у меня бы ушло куда больше времени вникнуть в код опенсурсной прошивки для чпу, чем добавить условие обработки концевика. Возможно вы одну из таких прошивок сами написали?
Судя по фотографии шаговый двигатель без обратной связи (без энкодера), если случайно в момент открытия произойдет скачек напряжения или отключится сеть то штору предется перенастраивать. Судя по коду там такой защиты не предусмотрено. А ведь так и штору может намотать в обратную сторону - что не особо страшно. А страшно здесь чтобы конструкция не сломалась, так как момент силы у шагового двигателя с редуктором довольно большой.
Ну и в целом когда работа шагового двигателя сводится к постоянному подсчету шагов на длительный промежуток времени, тот тут возможна ситуация накопления ошибки.
Я бы установил один концевик который бы мог срабатывать когда штора открыта (поднята), как на фотографии сверху.
При подъеме шторы происходит его срабатывание и подъем шторы останавливается. А в программу поступает сигнал о том что можно сделать сброс счетчика шагов, так как штора в вверхнем положении.
С помощью этого концвика можно предусмотреть сценарий отключения сети, примерно так: при начале движения шторы в постоянную память записываем байт 1 - идет движение. Когда движение завершено - записываем 0. Есть питание отключиться в движении, то при запуске программы будет прочитан байт, что последний раз было движение, и никто не знает где оно остановилось. Запускаем аварийный режим, когда штора поднимается вверх до срабатывания концевика.
Да и просто можно на плате установить одну кнопку: "калибровка" - когда шаговый двигатель начинает мотать штору вверх до срабатывания концевика.
Рыба гниет с головы!
От вас требовали вовлеченности в процесс сотрудников, но руководство видимо не поняло что вовлеченность в процесс зависит прежде всего от них самих. Это ТОПам нужны психологи, если они не понимают почему их сотрудники не вовлечены в процесс. Но менять себя сложнее, гораздо проще кого то нанять чтобы он решил все их проблема и переделал не вовлеченных сотрудников.
Если перефразировать вашу цитату то получается так: "Я не справился с этой задачей"
Я считаю что уровень компетенции психолога прямо зависит от того каким образом он может донести информацию и изменить пациента. Вы не приводите подробного описания блюдечка с голубой каёмочкой, но видимо руководство увидело совсем не это. Что ж, значит вашей компетенции было недостаточно чтобы что-то поменять.
Но! Вы получили ценный урок! И ценный опыт, над которым можно подумать, понять где были сделаны ошибки, исправить их и попробовать снова новый улучшенный подход.
P.S. Я не психолог, я программист.
Чем обоснован ваш выбор в пользу PNG, вместо более современного формата для вектороной графики SVG?
Вы проверяли как выглядет ваши смайлики на ретина дисплеях?
Делаете запас по пикселям для ретина дисплеев? (к примеру картинка 64px показывается как 32px)
И какое максимальное разрешение сохраняете для больших эмоджи? (у вас на скрине большой эмоджи в чате без другого текста)
Я тоже с вами согласен что глобальный стор нужно использовать на минималках, но когда я начинал все это делать хуков еще и в зачатках не было, поэтому мы выживали как могли.
Вам спасибо за разъяснение!
У меня была жесткая задача: 40 алертов а их надо по очереди показать, какие то алерты с возможностью выбора сценария, какие то сами схлопываются спустя время, а какие то при повторном вызове должне закрывать предыдущий. С помощью стора для алертов очень просто удалось это все порешать.
Но вот если у нас на экране два списка туду, порталы для алертов при рендере в боди наверно будут работать не так как ожидается: возможно один алерт будет висеть поверх другого. Так что здесь все зависит от задачи и целей которых нужно достигнуть.
Возможно у вас компонент алерты засунут внуть тудушки?
В своем проекте я делал алерты которые монтируются как отдельный компонент глобально почти что в самый root компонент. У алертов есть свой стор. Как только в этот стор тудушка кладет алерт он сразу отображается (алерты кстати точь в точь как вы и сказали сделаны: popout: { type, data }).
Я так сделал из принципа DRY — потому что вызвать алерт может не только тудушка.
В моей реализации компонент алерта общается с компонентом тудушки через стор (как вы сказали проброс пропсов сверху), но вот возникла задача как через стор прокидывать события из попапа обратно в компонент? (например событие удаления)
И здесь я решил остановится на варианте что в самих алертах уже буду запускать удаление. Удаление обновит стор и значит обновит тудушку.
У меня камень i5 2012 года выпуска и чтобы серфить интернет и запускать рабочие программы хватает с избытком. А теперь приходят ребята из винды и говорят что у тебя камешик то староват, иди в магазин да и бери ка себе новый камень. Только вот сокет поменялся, тогда и мать себе обнови. Что там у тебя dd3, не ну это совсем старье, сейчас ddX в моде. Ну блок питания можешь старый оставить, хотя не факт что разъемы совпадут.
Погодите, ну у меня комп так то нормальный?
Ну так нормальный он или не нормальный это твои проблемы, а через 3 года поддержка десяточки прикратиться.
Получается, что ребята из винды своими действиями говорят: да мы знаем, что у тебя комп норм, на ближайшие 10 лет поводов для обновления в виде увеличения скорости проца не предвидеться, а нам и нашим коллегам которые делают процы кушать хочется, поэтому иди и выкидывай на помойку свое старое железо. И нам все равно что это засоряет планету, мы же тебе прямо об этом не скажем. Мы лишь выпустим новый проц с новым чипом.
А я... А я... А я тогда ухожу с линуксом жить. Вот!
Что делать если израсходовал лимит на Github Actions а нужно срочно выложить релиз?
Вот уж не думал что все зайдет так далеко и идея с елочкой даст свои плоды. Почти год назад я в скетчапе накидал макет и теперь даже как то не вериться увидеть почти один в один его реализацию.
Почитайте мою последнюю статью здесь на хабре, я там описал проблемы со скролом и то как их решал.
№1. Проверка возврата скролла:
Скролю до 300го комментария, визуально запоминаю позицию скролла и смещение контента.
Нажимаю на рубрику в меню (All streams)
Нажимаю на кнопку вернуться назад
Итог: скрол не вернулся в то место на котором был.
№2 При обновлении страницы скролл возвращается не в том место в котором был
Вообще если бы я бы решал эту проблему, то я бы по другому бы все сделал. Поскольку я так понимаю у вас задача показать все комментарии на первом экране, то я бы начал с того что облегчил бы верстку по максимуму. SVG и картинки из первого показа должны быть убраны. Я бы так же убрал заглушки для картинок - они тоже жрут ресурсы. Блок под комментарием тоже бы скрыл но оставил бы под него место, поскольку он фикс-высота то его можно и потом через js показать. Ну и посмотрел бы насколько бы быстро загружалась бы подобная страница с такими комментариями, если скажим их 1000 штук. Собственно эта страница была бы эталоном скорости, максимум который можно получить. Т.е. эталон вообще не использует JS: только css и html.
Ну а после того как был показан первый экран, уже можно интерактивные элементы развешивать по DOM. Опять же зачем показывать картинку если я до нее не доскролил? Можно и не показывать. Даже интерактивные кнопки под комментарием можно рендерить только тогда когда они в видемой зоне скролла окажутся. Опять же тут проблема гидрации начинает подтягиваться все равно, и здесь в любом случае подвисание всего и вся если гидрировать все и сразу. А делать гидрацию только видимой обласит наверно сложно. Незнаю на сколько подходит для этих задач Vue js, к сожелению не разу его так и не попробовал, зато могу сказать про React. Ну собственно те проблемы что вы описали с перерендером всех комментариев при обновлении рейтинга я в tolstoycomments тоже испытал и на React. Я тоже эксперементировал с кол-во комментариев на страницы и адекватной скоростью их рендера. В итоге я пришел к выводу что больше 130 каментов на странице не показываю. Т.е. прокрутка вверх/вних скрывать каменты снизу/сверху. Конечно у нас виджет и подход немного другой. Проблема с восстановлением скролла решена частично. Проблемы с прокруткой скролла и смещенеим тоже решена частично. Олаживать работу скролла эта конечно очень не простое занятие.
По React могу сказать что как только я отказался от классовых компонентов и переписал все на чистые функции, скорость заметно выпросла. Конечно я думаю что я просто в первый раз код был написан просто не очень удачно и в этом была проблема:) Ну и да, нужно следить за тем чтобы не делать лишних рендеров если по факту ничего в компоненте не поменялось.
Жалко что вы не выложили готовый результат куда-нибудь чтобы можно было сразу его потыкать. Ок, выполняем магическую комбинацию из команд:
На самом деле ваш скрипт можно доработать, а именно если сообщений слишком много то сделать так чтобы они не все сразу показывались, а отображались пачками, например в одно время у ВК был придел 3 сообщения. А потом остальные показывались только когда появлялось свободное место, т.е. когда одно из 3х сообщений закрывалось. Некий аналог стека. Думаю с помощью RxJs это было бы особенно эффектно реализовать.
Ну и верстка может ехать при определенных размерах страницы на мобиле. Конечно это демка, но если кто-то вашу реализацию будет брать в продакшен, верстку нужно будет править.
Как узнать что изменений больше не будет?
Проблема с scrollintoview что с ним не получится восстановить скролл на том месте, на котором пользователь был ранее.
Да, вы правы, проблема в том что я не знаю финального scrollHeight. А узнать его можно только после того как компоненты с изменяемой высотой будут отрендерены на странице. По сути scrollHeight можно узнать после вызова события onRenderChildrenComplete
И да, я должен снять перед вами шляпу, потому что как то давно еще видел у вас как раз реализацию с динамическим скролом, который автоматически подгружал нужные данные в нужном положении скролла (кажется это был некий grid). Собственно по аналогии как это было реализовано у вас я и реализовал это в своем текущем проекте.
Статью по ссылке не видел, прочитаю, спасибо!
Да, спасибо, ошибочка вышла. Отсутствие нейтив инглиша и собственная безграмотность часто меня приводят к подобным ошибкам.
Не все читал ваши предыдущие статьи, и возможно ответ на мой вопрос уже писали, но все же интересно. А такая схема разве не эффективнее?
Пример
Я разработчик на C# и что-же мне делать?
В моем случае
.Where(n => n.Items.Count() == 0)работало шустрее в разы. Да и в дальнейшем я понял что лучше в LINQ Any вообще не использовать и делать все на Count. К сожалению пока нет возможности сделать ToString обоих запросов.MSSQL и EF это отдельный, уникальный и дивный мир! Я в вебе с тех самых времен, когда верстали еще под IE6, и навыки верстака оценивались знаниями как выравнить блочный элемент по центру, как сделать прозрачность или как не словить баг с margin.
Прошло 15 лет и ничего не поменялось. Я по прежнему занимаюсь шаманством. Переписываю запрос LINQ c `.where(n => n.PropABool && !n.PropBBool)` на `.where(n => n.PropABool == true && n.PropBBool == false)`
Запрос вроде вашего `.Where(x => x.DisplayName.StartsWith(key))` это вообще не позволительная роскош! Нет, тут только полнотекстовый поиск, там все норм со скоростью работы, а обычный like использовать на больших полях опасно!
Вот еще такой пример: `.Where(n => !n.Items.Any())` или `.Where(n => n.Items.Count() == 0)`. Вопрос к знатокам, какой будет работать шустрее?
Здесь все зависит от личного опыта. В текущем проекте и так уже подключена стандартная библиотека управления AccelStepper. Для текущего проекта ее вполне достаточно. Добавить обработку концевика - это еще несколько ифов в программе.
Думаю у меня бы ушло куда больше времени вникнуть в код опенсурсной прошивки для чпу, чем добавить условие обработки концевика. Возможно вы одну из таких прошивок сами написали?
Судя по фотографии шаговый двигатель без обратной связи (без энкодера), если случайно в момент открытия произойдет скачек напряжения или отключится сеть то штору предется перенастраивать. Судя по коду там такой защиты не предусмотрено. А ведь так и штору может намотать в обратную сторону - что не особо страшно. А страшно здесь чтобы конструкция не сломалась, так как момент силы у шагового двигателя с редуктором довольно большой.
Ну и в целом когда работа шагового двигателя сводится к постоянному подсчету шагов на длительный промежуток времени, тот тут возможна ситуация накопления ошибки.
Я бы установил один концевик который бы мог срабатывать когда штора открыта (поднята), как на фотографии сверху.
При подъеме шторы происходит его срабатывание и подъем шторы останавливается. А в программу поступает сигнал о том что можно сделать сброс счетчика шагов, так как штора в вверхнем положении.
С помощью этого концвика можно предусмотреть сценарий отключения сети, примерно так: при начале движения шторы в постоянную память записываем байт 1 - идет движение. Когда движение завершено - записываем 0. Есть питание отключиться в движении, то при запуске программы будет прочитан байт, что последний раз было движение, и никто не знает где оно остановилось. Запускаем аварийный режим, когда штора поднимается вверх до срабатывания концевика.
Да и просто можно на плате установить одну кнопку: "калибровка" - когда шаговый двигатель начинает мотать штору вверх до срабатывания концевика.