BEARlogin Dev

Вопрос Есть такой метод

class UserService {
...
  async updateUser(id, data) {
    await this.user.update(id, data);
    await this.logger.log('User updated', id, data);
  } 
...
}

Не спрашивая у chatgpt скажите, что тут не так? Upd1. С кодом, входными данными все в порядке, дело в другом. Ответ напишу в 13.30

Шок контент: разраб осознал опасность нейросетей BEARlogin dev — подпишись!

Заменит ли AI разработчиков? Думаю, каждый об этом задумывался. И слышал противоположные мнения: от того, что да, всех заменит железный болван, до того, что волноваться не о чем. Но истина всегда не на максимумах или минимумах. Она посередине. AI УЖЕ заменил разработчиков. Но не так, как ты думаешь. Он не пришёл и не сказал: «Всё, кожаный мешок, твоё время ушло, теперь кодим мы». Он изменил систему. Сильные разрабы стали ещё сильнее. По сути, AI — это экзоскелет, который усиливает твои способности. Если ты ходить не умеешь, экзоскелет не поможет. Скорее, твои навыки ещё больше атрофируются. Так что AI не заменяет людей, но делает сильных сильнее, а слабых — бесполезными. Так работает естественный отбор. А вы что думаете по этому поводу? P.S. я советую людям, которые сейчас проходят обучение на разраба - вырубайте AI помощников, совсем, наглухо. Можно пользоваться только AI-чатами, чтобы лучше разобраться в какой то теме, и то, не факт что вам верно чатгпт все объяснит. Может такую ахинею занести, что на собесе просто ржать все будут. —- Делаю слабых сильными, чтобы вас не заменил AI или чтобы пройти испытательный срок и не вылететь, пишите в ЛС @bearlogin — разберемся :) BEARlogin dev — подпишись!

Скинули тут новую UI либу https://www.neobrutalism.dev/ Привлекли отзывы...

Жена звонит: — Где твоя машина? На парковке нету... Я завис... 🤔 Где машина-то?.. Вспоминаю: остановился у кафе, зашел, поел… и ушел домой пешком. 🚶‍♂️ Определенно пора отдохнуть. 😅

Произошла ошибка попробуйте позже

Раз Андрей высказался, то и мне пора: моя история участия в токсичном стартапе

еще один пострадавший

Знаете, сейчас многие пишут: "Блин, а вот вдруг оно выстрелит, а ты не дождался. Не будет обидно?" Но дело совсем не в этом. Этот выход — это победа. Я победил FOMO длиной в 2,5 года. Это результат полугодовой трансформации. Еще летом, в июле, я наткнулся на SkillsLab и начал изучать коммуникацию, манипуляции и практики противодействия. Потом прочитал книгу Никиты Непряхина "Я манипулирую тобой". И в какой-то момент я УВИДЕЛ. Как будто шоры спали. Я прозрел и наконец-то разглядел всю сеть манипуляций, психологического насилия и контроля, которой опутали меня и всю команду. Это было как в Матрице — как будто принял красную таблетку. После этого я пытался повлиять на ситуацию. Прямо говорил фаундерам, что они манипулируют, что это вредит проекту, что люди выгорают из-за их подхода. Но не достучался.

"Выгорания не существует. Это просто слабые люди собрались и не смогли дойти на Эверест."

Таков был их ответ. А дальше произошёл случайный, но ключевой момент. Я наткнулся на пост Айюба, где он рассказывал, что работа с коучем помогла ему прочистить мозг. До этого я уже искал коуча, но всё время натыкался на каких-то цыган. Но тут Айюб поделился контактом. Я написал и пошёл в работу. Буквально за два занятия я начал приходить в себя. Я понял, чего я хочу, куда двигаться, с кем работать и кем быть. Мы разобрали всю ситуацию со стартапом. И коуч задал мне один вопрос, который всё решил:

Андрей, за сколько ты был бы готов и дальше подвергаться психологическому насилию?

Я задумался и ответил: "Ну… за миллион долларов в месяц." Тогда последовал второй вопрос:

То есть ты утверждаешь, что люди имеют право применять психологическое насилие, если платят миллион долларов?

Я задумался. И сказал: "Нет." Тогда коуч повторила первый вопрос:

Андрей, за сколько ты был бы готов и дальше подвергаться психологическому насилию?

И в этот момент всё стало ясно. Я ответил: "Ни за сколько." BEARlogin dev — подпишись! #стартапы #манипуляции

Знаете, сейчас люди пишут, спрашивают, что вот, а вдруг стартап выстрелит, а ты недождался

Я теперь могу говорить, что собрал Бинго 8\8 токсичного стартапа. Ну, тоже опыт...

Zustand подписка только на конкретные изменения стора Если вам нужно подписаться на изменение какой то части стора, то используйте миддлварь subscribeWithSelector

import { create } from "zustand";
import { subscribeWithSelector } from "zustand/middleware";

const useStore = create(
  subscribeWithSelector((set) => ({
    count: 0,
    user: { name: "Alice", age: 25 },
    increment: () => set((state) => ({ count: state.count + 1 })),
  }))
);

// Подписка ТОЛЬКО на `count`
useStore.subscribe(
  (state) => state.count,
  (newCount, prevCount) => {
    console.log(`Счётчик изменился: ${prevCount} → ${newCount}`);
  }
);

Теперь подписка сработает только при изменении count, а изменения user её не триггерят. -- Подготовлю к собесам, помогу с рабочими задачами и росту хардов/софтов. Уперся в потолок с з/п, ответственностью? Помогу с ростом грейда от миддла до синьора. Если необходимо менторство - пишите @bearlogin BEARlogin dev — подпишись! #react #zustand

Тут пишем отзывы по менторской работе со мной. Только отзывы, остальные сообщения удаляю.

Зачем нужен useSyncExternalStore Вопреки расхожему мнению, оно нужно не только для подключения внешних стейт-менеджеров. Эта штука в целом работает с внешними источниками состояний. Что такое этот источник состояния? В целом интерфейс евойный состоит из двух трех функций: 1. subsribe - которая используется, чтобы подписаться на изменение чегобытонибыло 2. getSnapshot - которая используется, чтобы получить то самое чтобытонибыло 3. getServerSnapshot - которая используется, чтобы это самое чтобытонибыло на стороне сервере При ближайшем рассмотрении весьма и весьма полезная штукенция... Рассмотрим пример с созданием хука для отслеживания изменения ширины окна

//Без  useSyncExternalStore
function useWindowWidth() {
  const [width, setWidth] = useState(window.innerWidth);

  useEffect(() => {
    const handleResize = () => setWidth(window.innerWidth);
    window.addEventListener("resize", handleResize);
    return () => window.removeEventListener("resize", handleResize);
  }, []);
}

export default function WindowWidthComponent() {
  const width = useWindowWidth();

  return <div>Ширина окна: {width}px</div>;
}

//Вариант с useSyncExternalStore

import { useSyncExternalStore } from "react";

function useWindowWidth() {
  // Подписка на изменения
  const subscribe = (callback) => {
    window.addEventListener("resize", callback);
    return () => window.removeEventListener("resize", callback);
  };

  // Читаем текущее состояние
  const getSnapshot = () => window.innerWidth;

  return useSyncExternalStore(subscribe, getSnapshot);
}

export default function WindowWidthComponent() {
  const width = useWindowWidth();

  return <div>Ширина окна: {width}px</div>;
}

Или вот восхитительная тема с mediaQuery

import { useSyncExternalStore } from "react";

function useMediaQuery(query) {
  const mediaQuery= window.matchMedia(query);

  const subscribe = (callback) => {
    mediaQuery.addEventListener("change", callback);
    return () => mediaQuery.removeEventListener("change", callback);
  };

  const getSnapshot = () => mediaQuery.matches;

  return useSyncExternalStore(subscribe, getSnapshot);
}

export default function MediaQueryComponent() {
  const isLargeScreen = useMediaQuery("(min-width: 1024px)");

  return (
    <div>
      {isLargeScreen ? "Большой экран" : "Маленький экран"}
    </div>
  );
}

А в чем разница под капотом? Она как суслик, ее не видно, но она есть. 1. Поддержка Concurrent Rendering — гарантирует согласованность состояния даже при приостановке или перезапуске рендера. 2. Мгновенная синхронизация — состояние всегда актуально на момент рендера, без задержек, свойственных setState. 3. Меньше лишних ререндеров — React сравнивает значения из getSnapshot и вызывает рендер только при изменении. 4. Поддержка SSR и гидрации — позволяет задать серверное состояние через getServerSnapshot, устраняя расхождения между сервером и клиентом. В общем, интересная тема, на мой взгляд, нужно брать! Подготовлю к собесам, помогу с рабочими задачами и росту хардов/софтов. Уперся в потолок с з/п, ответственностью? Если необходимо менторство - пишите @bearlogin BEARlogin dev — подпишись! #собеседования #react

Пока я не очень в состоянии писать полноценные посты, буду делиться интересной инфой, что нашел. Сегодня вот интересная инфа по задержкам https://gist.github.com/jboner/2841832. При этом в комментах есть свой "юмор", типа расчета задержек в бананах 😀

Не тяните с обращением к врачу. Я вчера понял, что если кашляешь месяц, то стоит сходить к врачу, а не ждать, что все пройдет само. Даже если температуры нету. Пневмония 🤧 #заболел

Вот кто ставит 👎, вы там покажитесь, комент напишите, или вы на бобину обиделись? 😀 Или это один человек 6 аккаунтов зарегал, сидит ставит? Прост тема холиварная, понимаю, ну давайте похоливарим.

FSD: дело было не в бобине... Часто слышу критику FSD: "Слишком много папок, слишком много правил, это избыточно!". Но хочу сказать, что FSD — это не про количество папок. Это про направление зависимостей и архитектурные границы. Ты не обязан сразу строить многоэтажный небоскрёб, если у тебя пока маленький проект. Начать можно просто.

Кстати, само название FSD (Feature-Sliced Design), на мой взгляд, не совсем корректно. Это не "дизайн, разделенный на фичи". Скорее, это методология, которая помогает структурировать код, организуя его вокруг бизнес-функционала и уровней ответственности, позволяя соблюдать принципы Low coupling и High cohesion. Можете в комментариях предложить своё название. Лично я бы назвал это Business-Sliced Design — чтобы невозможно было интерпретировать методологию упрощённо и требовалось изучение её сути.

С чего начинать? На старте достаточно трёх слоёв: 1. app/ — конфигурация приложения: роутинг, провайдеры, глобальные стили. 2. shared/ — переиспользуемые, не связанные с бизнесом компоненты, утилиты, стили и т.д. 3. pages/ — страницы приложения и используемые ими компоненты.

src/
  app/
    App.tsx
    routes.ts
  shared/
    ui/
      Button/
        index.tsx
  pages/
    catalog/
      ui/
        CatalogPage.tsx
        ProductList.tsx //кандидат на вынос
      index.ts
    recommended/
      ui/
        RecommendedPage.tsx
        ProductList.tsx
      index.ts

Сначала можно оставить всё в pages, если функциональность используется только там. Но как только начинаешь дублировать код, либо твой слайс хочет что то импортировать у соседей, то логично вынести его в widgets.

src/
  app/
    App.tsx
    routes.ts
  shared/
    ui/
      Button/
        index.tsx
  widgets/
    product-list/
      ui/
        ProductList.tsx
      model/
        useProducts.ts
      index.ts
  pages/
    catalog/
      ui/
        CatalogPage.tsx
      index.ts
    recommended/
      ui/
        RecommendedPage.tsx
      index.ts

А затем продолжаешь углублять структуру. Например, если два widget используют схожую логику или функциональность, то логично вынести её в features. Дальше это движение продолжается по мере необходимости. Что касается entities и shared, то здесь есть определённая специфика. Об этом я расскажу в следующих постах. Вынос в новый сегмент какого то функционала не является самоцелью. Я бы сказал, даже наоборот — если можно не выносить и остаться в рамках одного слайса — оставайтесь. Таким образом FSD подходят для любых проектов на старте, позволяя сразу закладывать возможности для масштабирования и помогает соблюдать принципы низкой связанности и высокого зацепления. Ставьте 🔥, если хотите больше практических примеров и советов по FSD. BEARlogin dev — подпишись! P.S. советую этот экстеншн для генерации слайсов https://marketplace.visualstudio.com/items?itemName=SbokyZahodi.fsd-slices #архитектура #frontend #fsd Подготовлю к собесам, помогу с рабочими задачами и росту хардов/софтов. Уперся в потолок с з/п, ответственностью? Если необходимо менторство - пишите @bearlogin