tgindex

BEARlogin

описание

BEARlogin — канал про то, как один усталый батя строит AI-продукты, вайбкодит в 16 окон, чинит прод, материт Kubernetes и иногда случайно делает бизнес. Канал с хокку тут https://t.me/devs_hokku Рекламу не беру

← к каналу@bearlogin_dev
706
подписчиков
Охват к подписчикам
80,9%
ERR
Реакции к просмотрам
1,69%
533 на 37 постов
Пересылки к просмотрам
1,27%
399
Постов в день
0,0
всего 37

Где отзываются чаще

доля реакций к просмотрам
  • 22 янв. 2025 г.Что происходит в момент, когда мы вызываем setState? Многие говорят, что обновляется state. Но это не совсем так. Приведу пример const [count, setCount] = useState(0) function updateCount(value) { setCount(value); console.log(count); // в этом месте много людей на собесе говорили мне, что console.log выведет значение value } Работа с функциональными компонентами создаёт иллюзию, будто мы оперируем с императивным подходом: то, что мы видим, — это и есть реальность. Но это лишь фасад. На самом деле React использует декларативный подход. (Я вообще молчу, что у нас count объявлена константой и чисто физически не может изменится) Что это значит? Это значит, что мы говорим React, какое состояние компонента хотим получить. А дальше начинается магия: React планирует изменения, запускает рендер, и мы не знаем точно, когда состояние действительно обновится и изменения попадут в реальный DOM. Внутренности процесса Когда React обновляет дерево компонентов, он делит эту работу на кусочки. Почему? Чтобы уложиться в определённое время — около 16.6 мс на кадр при 60 fps. Если React не успевает, он приостанавливает процесс и продолжает позже. Но на этом всё не заканчивается. Когда рендер завершён, React сверяет новое дерево с предыдущим (reconciliation). Только после этого, одной синхронной задачей, обновляется реальный DOM — это называется "коммит". Если интересна такая "внутрянка" React ставьте 🔥 и я раскрою глубже, как происходит render, сверка, что такое Fiber и т.д. BEARlogin dev — подпишись! #react #advices #собеседования6,71%
  • 23 янв. 2025 г.Камрад в коментах упоминул про случай, когда у нас множество обновлений, описанный в доке реакта и который любят спрашивать на собесах. У нас есть функция которая вызывает последовательно обновления state. const [count, setCount] = useState(0); const handleClick = () => { setCount(count + 1); setCount(count + 1); setCount(count + 1); }; Вопрос: чему в итоге будет равен count и сколько раз будет вызван render? Чтобы разобраться в этом, нужно понять как вообще планируются обновления. Такие вызовы — это тоже самое, что написать setCount(0 + 1) три раза. Очередь обновлений можно упрощенно показать так (подробней эту тему раскрою в постах про Fiber) baseQueue = { action: 1, next: { action: 1, next: { action: 1 } } } И когда React переходит к фазе рендеринга, он проходит по этом списку и применяет count равным 1 все три раза. В итоге рендер будет вызван 1 раз, а count = 1 Но если мы применим функциональные обновления setCount((prev) => prev + 1); setCount((prev) => prev + 1); setCount((prev) => prev + 1); То очередь обновлений будет выглядеть так baseQueue = { action: (prev) => prev + 1, next: { action: (prev) => prev + 1, next: { action: (prev) => prev + 1 } } } Во время рендеринга: Первое обновление: count = 0 + 1 = 1. Второе обновление: count = 1 + 1 = 2. Третье обновление: count = 2 + 1 = 3. В итоге render будет вызван всегда 1 раз в этих случаях, но в функции обновления мы будем всегда получать результат предыдущего обновления в параметры функции и в таком случае инкремент будет работать правильно. Другой вопрос, что будет если обновлений запланируется, ну скажем 100 000 сразу. Такой случай рассмотрю в следующих постах. ставьте 🔥 если зашло :) BEARlogin dev — подпишись! #react #advices #собеседования4,59%
  • 21 апр. 2025 г.Лучше пешком... Давно хотел попробовать электровел, даже хотел пойти курьером, но сказали — только со своим, поэтому отказался от этой затеи. Ок, значит, сегодня поехал тачку переобувать, и пока это дело происходит, решил доехать до ближайшего ТЦ — поесть, значит, и поработать. И вот, посмотрев, что пешком нужно так нехило пройти, да ещё через МКАД, решил взять самокат. Но, на мою беду, там ещё стояло это чудо техники. Быстро арендовав, сел такой — и поехал. Не сразу понял: а чё, собственно, крутить-то? Оказалось — нужно крутить педали. Ну ок, начал крутить, и — опа — магия: шайтан-машина набрала ход и покатилась. Ну ок, не так удобно, как самокат, где ручку повернул — и едешь, но сойдёт... Так я думал до первого перехода, когда понял, что эту ебалду нужно тащить на себе — наверх и вниз. Ну ок, напряглись, оттащили. И вот еду дальше — и чё-то он нихуя не едет. Ну прям с трудом идёт. Замечаю значок черепахи, вспоминаю, что такое бывает в пешеходных зонах. Ну ок, едем. Крутить педали становится всё тяжелее и тяжелее. Что, блин, происходит??! Смотрю в приложение — "Вы заехали в красную зону, тут нельзя кататься". Охуительно, думаю. И что дальше делать? А на ручной тяге-то я достаточно проехал, а до ТЦ ещё 1.5 км, и обратно в белую зону — столько же. Шайтан-машина ехать отказывается наотрез. Ну пофиг, попёр её до белой зоны, где ТЦ. Допёр, значит, на своих двоих. И вот я в белой зоне — но шайтан-машина так же нихера не едет, завершить аренду нельзя, так как она считает, что на огромной парковке будет кому-то мешать. В итоге пришлось переть через всю МЕГУ к сраной парковке для самокатов. Попутно разрядился телефон и разъебал ногу об сраный вел. И я так скажу — ну его нахуй, такое развлечение... #юрент #электровелы3,80%
  • 3 июл.Грузия и лифты Кароче, если кто не знает, в Грузии лифты платные, в основном электронные системы доступа, но бывают даже где монетки кидать в старых домах. В общем, у меня лифт по NFC метке работает, а чтобы курьер приехал, ему надо давать временный код, который меняется каждые 24 часа. Приложение, где эти коды сидят работает по принципу: 1 сессия - 1 аккаунт, то есть жене на мой аккаунт на телефон нельзя поставить приложение, сразу выбивает меня. В итоге мне надоело каждый раз лазить в приложение, и я написал управляющему домом, попросил добавить аккаунт жены в систему, чтобы она тоже могла смотреть коды. К хуям зареверсил их аппку и протокол, выяснил какие заголовки они шлют, запилил автоматизацию в Hermes. Сделал чат для жены, чтобы она моему Hermes писала и спрашивала код. Создал навык для Алисы, поднял на Rasberry Pi c Hermes вебхук, прокинул тунель через Cloudflare. Теперь я просто спрашиваю, "Алиса, скажи код от лифта". #легкийпуть3,70%
  • 8 маяСегодня встретил знакомого, он мне по-секрету поведал, что мессенджер мах это говно ебаное, а его разработчики — петухи ссаные. Я конечно ему не поверил, но кто знает...3,61%
  • 26 янв. 2025 г.Не тяните с обращением к врачу. Я вчера понял, что если кашляешь месяц, то стоит сходить к врачу, а не ждать, что все пройдет само. Даже если температуры нету. Пневмония 🤧 #заболел3,45%
  • 17 янв. 2025 г.Key в React Мы привыкли, что key используется только для рендера списков. Но использование key не ограничивается только этим. Изменение key показывает React что это другой компонент, и необходимо старый размонтировать, а новый замонтировать. Мы например можем добавить prop key к компоненту формы <UserForm key={userId} /> Таким образом если userId изменится, то вся форма размонтируется и смонтируется новая форма, и нам не придется обнулять значения формы руками при изменении пользователя. BEARlogin dev #react #advices #собеседования2,96%
  • 27 июл.Валера В общем, еще в догонку, навайбкодил тут кароче AI карьерного ассистента https://valerabot.com/welcome - Помогает с резюме, парсит тг каналы, hh, superjob и работные порталы компаний, - Проводит моковые собесы, ассесменты и дает нейрослоп интерактивные курсы. - Строит планы развития Вот вам промик - потестить BEARLOGIN - 10 собесов\ассесментов, курсы по 99р, задаром практически. Так же приглашайте знакомых, друзей, за каждого приглашенного - 100 рублей бонусов. Буду рад обратной связи2,83%
  • 19 янв. 2025 г.SRP как много в этом звуке... Буква S в SOLID вызвала больше холиваров и разбитых лиц чем React vs {anyFrontendFramework}. Его классическое определение - Класс должен иметь лишь одну причину для изменений. Что тут имел в виду Дядя Боб, да хер его знает этих гениев, скажем мы и пойдем дальше пилить таски из жиры. Но к счастью для нас он уточнил потом в Clean Architecture Модуль должен отвечать перед одним и только одним актором. Тоже нихера непонятно, но уже можно размышлять. Что есть актор? Актор — это кто-то или что-то, кто требует от твоего модуля выполнения задачи. Это может быть: - Пользователь, нажимающий на кнопки в интерфейсе. - Соседний модуль, который вызывает твою функцию. - Даже система, которая запускает твой код по расписанию. Каждый актор — это внешний драйвер, который влияет на твою логику. И вот что важно: модуль должен обслуживать только одного актора. Понятней не стало? Ок, приведем пример: class OrderService { createOrder(orderData) { // Покупатель создает заказ } getOrderDetails(orderId) { // Покупатель и менеджер получают информацию о заказе } updateOrderStatus(orderId, status) { // Менеджер меняет статус заказа } cancelOrder(orderId) { // Покупатель отменяет заказ } } Представим, что нам нужно для пользователя добавить возможность указать комментарий к заказу. Мы идём в OrderService и меняем его. А теперь нужно дать менеджеру возможность перенести доставку на другую дату. Мы снова идём в OrderService и меняем его. И вот тут всё встаёт на свои места. Вот она "причина" для изменений. Это вот этот самый актор — драйвер изменений. Итог: два актора на один класс. На лицо нарушение принципа SRP. Что делать? Разделить сервисы, чтобы они работали только с одним актором. // Модуль для покупателя class CustomerOrderService { createOrder(orderData) { // Логика создания заказа } getOrderDetails(orderId) { // Логика получения деталей заказа для покупателя } cancelOrder(orderId) { // Логика отмены заказа } createOrder(orderData) { // Логика создания заказа для покупателя } } // Модуль для менеджера class ManagerOrderService { getOrderDetails(orderId) { // Логика получения деталей заказа для менеджера } updateOrderStatus(orderId, status) { // Логика изменения статуса заказа } changeDeliveryDateTime(orderId, dateTime) { // Логика изменения доставки } cancelOrder(orderId) { // Логика отмены заказа } } Надеюсь вы теперь понимаете, насколько глубже был этот принцип, относительно упрощенной, ошибочной интерпретации "Один класс решает одну задачу." распространенной на просторах интернета. Вспоминается анекдот про "Рабинович напел" :) SRP не про то, что делает класс, а про причину его изменений. Про, если хотите, заказчика, драйвера этих изменений. P.S. Вы могли заметить, что для соблюдения SRP нам пришлось дублировать методы. А как же DRY??!! Я мог бы сказать перефразируя цитату классика Он нам и нах... не нужон DRY ваш! Но не буду, и расскрою эту тему в дальнейших постах, так как в архитектуре все зависит от контекста(с). STAY TUNE) BEARlogin dev — подпишись! #архитектура #advices #solid2,76%
  • 3 июл.Охуительная история. Сделал, чтобы мой бот Hermes, если в него левые люди стучатся, присылал это видео. Но вот незадача, у меня он подключен как бизнес ассистент, в итоге он слал это видео, всем кто мне писал в лс. Многие оценили, некоторые обиделись 😄2,73%
  • 19 февр. 2025 г.без подписи2,27%
  • 23 июн.так и представляю, в антропике сидит SRE и пишет клоду, "блять давай быстрей сучий ты потрох, все легло, тупой ты говнюк!" — А он ему — "API Error: 500 Internal server error".2,19%