Кажется, я придумал новую архитектуру ивентов и мне она нравится

[eliminator123]

мне кажется самое интересное - это декларативная разметка отправляемых событий. Это позволило бы условно говоря "программировать мышкой".

[cupraer]

все ивенты обрабатываются в единственном обработчике

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

[happy-mama]

80к элементов на карте прекрасно отрабатывали без единого подлагивания

[cupraer]

Отрабатывали что именно?

[happy-mama]

Второй блок кода в статье.

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

[winkyBrain]

я не знаю теорию js

Зато придумал новую архитектуру ивентов. Но

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

Удивительно) ещё и подход заточен под конкретную библиотеку react, которая создана для работы с картами - а у этого явно есть своя специфика.

Базовое использование выглядит так:

useEffect(() => {
  // проверяем необходимость обновить коллбек
  if (tool == "pin" && drawmode) {
    
    // создаем простую функцию как и всегда
    let handleClick = (e: MapMouseEvent) => {
      //
      // логика
      //
    };

    // вешаем ивент
    ME.click.pin = (e) => handleClick(e);

    return () => {
      // удаляем по необходимости
      ME.click.pin = (e) => () => {};
    };
  }
}, [...]);

Выглядит ужасно. То есть каждый раз, когда нужно повесить новый хендлер на onClick по конкретному элементу, мы вместо этого устанавливаем какой-то глобальный onClick, который будет меняться вот так в каждом useEffect?

На самом деле уже давно придумали такую штуку, как делегирование событий. Когда например вместо того, чтобы вешать 10 хендлеров на 10 одинаковых по функционалу дочерних элементов, мы вешаем 1 хендлер на родителя, вытащив id потомка(или что нам нужно для успешной обработки события) через event.target. Вам возможно именно этого и не хватало? В любом случае незнание базы языка вряд ли может привести к каким-то действительно серьёзным открытиям/новым архитектурам. Скорее наоборот, в данном случае второго буквально вытекает из первого, причём вытекает сомнительного качества

[happy-mama]

А зачем вешать ивент на конкретный элемент? как раз от этого я и бежал когда выдумывал эту архитектуру. Вешаешь 1 хендлер для текущего режима управления пользователя и логикой внутри хендлера уже и определяешь действие которое нужно совершить. Этот код себя прекрасно показал на датасете с 80к кустиков в париже, обрабатывая все 1 ивентом.

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

[VanKrock]

Возможно это специфика js, что всё выглядит странно, но сама задача и подход в её решению, выглядит так, как будто вы хотите применить паттерн медиатор, в js я беглым поиском не нашёл ничего толкового по этой теме, но в С# есть такая библиотечка как MediatR и всё выглядит так, что вы хотите применить нечно подобное в js

[Tishka17]

Мне кажется Mediatr называть реализацией паттерна медиатор не вполне корректно. Это все таки центральная шина, которая требует отправитель затачивать под нее и делать встраиваемые обработчики. В то время как классический медиатор просто про наличие источников событий и использование медиатора как их обработчика, делающего полезную работу.

[Riim]

Вроде как обычное делегирование событий. Идее одного обработчика на весь документ то же сто лет уже. Ничего нового не рассмотрел.