быть принят на стороне апи раньше первого? Если они отправлялись почти одновременно
да
Как тогда контролировать, какие изменения более актуальные и их следует применить? Добавлять timestamp какой-то в риквест?
нет, просто брать результат последнего тащемта тема для @js_ru
Ращные есть стратегии, можно и иак
Если важна последовательность - то нет
последнего - последнего запроса
Ну так надо понять какой был последний Для этого надо их маркировать Порядок же не гаранитируется протоколом
🤔 так на руках объект промиса, всегда можно понять, какой реквест был последний, храня ссылку на промис от последнего запроса
Почитай изначальный вопрос Откуда на стороне апи экземпляр промиса?
Почитай последующие ответы Зачем стороне апи хранить актуальность данных в контексте последовательных вызовов? 99/100 тут речь про последовательные запросы с клиента, которые могут завершиться в неопределенном порядке
Как пример два запроса, оба меняют те же данные, но во втором более актуальные. Если апи сохранит последним данные из 1 запроса, то это же будет не правильно
Вопрос был в том может ли апи получить запрос с менее актуальными данными последним, раз по протоколу порядок не гарантирован, то получается может
ок, сори, не так понял вопрос но тогда резонно спросить, зачем задавать его в чате по реакту?
В чате по Реакту не вполне уместно, но все же нашлись те, кто смогли подсказать, тема близкая
скорее неуместно вовсе как беляш приготовить тоже тут спросишь? все кушаем, для всех тема близкая
причем ты замечал, что бывает, ты его первым положил на сковородку, а он пожарился вторым, magic
Аналогия не корректная) Не цепляйся, вопрос закрыт
да, ручкой просто время начала приготовления на нем написал, помогло!
да уж сам разберусь, к кому цепляться, к кому нет
аналогия мб и некорректная но просьба воздержаться в будущем от вопросов не по теме
Ок. Буду воздерживаться. Но так то в чате всегда хватает сообщений, ещё дальше от темы Реакта, чем мой вопрос. Разница только в том, отпишется ли кто-то, кого это зацепило
Обсуждают сегодня