Думал, что событие срабатывает на начале или завершении, судя по док-ции, практически во всех браузерах оно срабатывает тактами, серией событий на каждый сдвиг. Просто если использовать как заглушку алерт, то срабатывает два раза, на консоль.лог уже 6 раз. Поэтому, да, видимо нужен таймер с какой-то визуальной "вертушкой" и вероятно вернусь к варианту intersection observer.
Всем спасибо.
Решения типа установки таймера, флага и пр. можно использовать как вспомогательные, когда необходимо сгладить какие-то шероховатости, в общем речь о чистовой доработке. В моем случае явный баг с дублированным вызовом события. При любом смещении происходит два вызова события.
WbICHA, использовал все что только можно .... Этот вариант, который я привел, прямо скажем так себе .....например, он учитывает попадание в зону срабатывание, но не направление и пр. Суть не в этом. Я не могу понять почему событие двойными вызовами идет. И нигде нет инфы, 100-пудово это какая-то типично реактовская приблуда. Как ее "прибить", вот в чем вопрос?
Думаю было бы разумно также закрывать соединение, как пример навигация в приложении, пользователь переходит на другую страницу.... но хотелось добавить что-то вроде этого (https://developer.mozilla.org/en-US/docs/Web/API/B...) для получения уведомлений в зоне видимости всего приложения в течении всего сеанса работы, неважно в какой части раздела пользователь. По идее EventSource нужно перенести в другой компонент, уровнем выше.
Вот пообщаешься со спецом и сразу и идеи появляются и "косяки" выявляются ).
szQocks, я поудалял лишний код для примера. Собственно при перезагрузке, обрыве и прочего, соединение закрывается и пересоздается, респонз клиента на сервере тоже (либо удаляется). Убрать в юхэффект EventSource можно, но это не критично. рендерится один раз, дальше загружает диалоги либо на событии при достижении границы скролла, либо когда прилетает диалог из апи от друих сервисов. Без SSE никак в моем случае. Альтернатива веб-сокеты или лонг поллинг. Пока остановился на SSE, потом возможно поменяю на веб-сокеты. Сейчас все равно пока прототип "пилю". Важно получить рабочую версию как можно быстрее.
Да, большое спасибо, этот вариант рабочий. Я что-то перемудрил вчера и такой вариант даже не стал пробовать, оказалось зря.
SSE использую, потому-что ответ в мой апи идет от другого сервиса, через веб-хук, как приходит ответ, апи пересылает клиенту. Можно было веб-сокеты заюзать, возможно потом так и сделаю, сейчас проще SSE.
Насчет async, да это там лишнее, удалял наскоро.
Спасибо, но его там нет. По идее, если требовались бы дополнительные заголовки указывать, то в консоли была бы такая возможно, ну и + упоминание в доках, но этого нет. Я честно говоря офигеваю от этого. Вроде бы 400 намекает на то, что пропущен какой-то required param или header, но ошибка есть, а в оаписании ничего нет.
Dimonchik, ну это больше история про маркетинг. А тут проблема в том, чтобы оптимально выстроить процессы в программе для конечного пользователя . Ориентироваться на мнение первых клиентов не совсем верная стратегия. Во-первых слишком малая выборка, не факт что дадут правильные рекомендации, во-вторых продукт ужк будет сделан и что-то глобально переделывать, так себе затея. Если говорить про бизнес анализ....Читал по этой части, понимаю и чувствую необходимость, но непонятно как привлекается к проекту подобный специалист. Скорее всего это уровень крупного инвестора. Я думаю нужен хороший специалист-управленец именно того уровня бизнеса, для которого предназначена программа. Вопрос где и как его искать? Наверняка 100500 раз уже задавались этим вопросом тысячи людей, странно что еще ничего не придумано в виде каки-то площадок, сервисов?
Да я сам действующий сотрудник в компании, которая разрабатывает crm-и erp- систему. ) Все варианты, кроме третьего, использованы лично - общаюсь + работаю с чем-то похожим, в общем ориентируюсь. Тем не менее это блуждание в темноте и наощупь. Так многие делают, но это крайне рискованно, фактически релиз продукта на авось, очень велик шанс пролететь с треском.
Максим, дружище, не лезьте в бутылку на ровном месте ) Ваше решение очевидно костыльное. Воткнуть костыль перед чем-то куда-то, всякие там before и прочее, тут большого ума не надо.) Я вам конкретно написал, что строгая типизация, например в случае некоторых механизмов моделей (тех же валидаторов) вступает в противоречие с тайп хинтами в пыхе. Скорее всего потому, что архитектура фреймворка закладывалась задолго до них.
п.с. .... голова, руки и даже жопа у меня присутствует, если что...
Нет, тут апи как раз и получает данные, а вот что ему пришлют......Преобразовывать данные перед установкой свойств модели не есть гуд. Во-первых все шансы в лучших традициях пыхи на входе получить лошадь, а на выходе лопату. Во-вторых, в принципе модель этим и должна заниматься. А тут пойдут проверки не там где надо, либо появление новых сущностей на ровном месте. Я просто склоняюсь к мнению, что с тайп хинтами нужно быть осторожнее, грубо говоря, логика фреймворка ломается. Я как раз придерживаюсь другого мнения, что строгая типизацация на пыхе, как седло на корове ))
Экспресс-то рулит, но пустой как барабан, по-сути одна обертка над нодой, респонз, реквест, да мидлваре (насколько я помню), а хотелось бы какого-то минимального функционала, чтобы свои "велосипеды" не писать. Странное дело, более или менее продвинутых js-Фреймворков фактически нет.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Всем спасибо.