c
он располагается в common
Size: a a a
2021 January 28
c
если ты посмотришь
AI
Ну вот у меня есть нпм с твоим кодом. Там идёт персистинг кук, хотя я этого не ожидаю. Мне лезть в кишки нпм ?
c
Ну вот у меня есть нпм с твоим кодом. Там идёт персистинг кук, хотя я этого не ожидаю. Мне лезть в кишки нпм ?
бля
AI
Я об этом
c
не надо подменять
c
мы начали о том, что есть серверная реализация
c
и клиентская
c
теперь обсуждаем КОНКРЕТНУЮ реализацию для ССР
c
никто не будет выносить в нпм код с персистингом кук
c
но при этом можно унести код requestInternalFx
c
и построить обычный пайплайн
c
ещё раз разница
мой пример:
user -> request -> abstraction ( -> adapter)
ваш пример:
user -> request -> (***) -> adapter
и проблема этих звездочек, что код интерсептора может быть ГДЕ УГОДНО. и там может быть абсолютно всё что угодно.
для читающего код всё выглядит так:
user -> request -> adapter
но на деле там может происходить всё что угодно
мой пример:
user -> request -> abstraction ( -> adapter)
ваш пример:
user -> request -> (***) -> adapter
и проблема этих звездочек, что код интерсептора может быть ГДЕ УГОДНО. и там может быть абсолютно всё что угодно.
для читающего код всё выглядит так:
user -> request -> adapter
но на деле там может происходить всё что угодно
c
Фига се, это транспорт, который очень отличается. И дело в том, что у тебя в зависимости от транспорта может пойти что-то не так
так с интерсепторами ты полностью теряешь такую возможность.
ты просто втыкаешь интерсептор в любой момент
притом, что зачастую важен ещё порядок добавления
ведь иначе может сломаться
ты просто втыкаешь интерсептор в любой момент
притом, что зачастую важен ещё порядок добавления
ведь иначе может сломаться
AI
ещё раз разница
мой пример:
user -> request -> abstraction ( -> adapter)
ваш пример:
user -> request -> (***) -> adapter
и проблема этих звездочек, что код интерсептора может быть ГДЕ УГОДНО. и там может быть абсолютно всё что угодно.
для читающего код всё выглядит так:
user -> request -> adapter
но на деле там может происходить всё что угодно
мой пример:
user -> request -> abstraction ( -> adapter)
ваш пример:
user -> request -> (***) -> adapter
и проблема этих звездочек, что код интерсептора может быть ГДЕ УГОДНО. и там может быть абсолютно всё что угодно.
для читающего код всё выглядит так:
user -> request -> adapter
но на деле там может происходить всё что угодно
для юзера, который вызывает код, выглядит всё вот так
user -> call -> response
и всё, что происходит между call и response, хоть с твоим реквестом, хоть с аксиосом, будет неявно до тех пор, пока не полезешь в кишки
user -> call -> response
и всё, что происходит между call и response, хоть с твоим реквестом, хоть с аксиосом, будет неявно до тех пор, пока не полезешь в кишки
c
для юзера, который вызывает код, выглядит всё вот так
user -> call -> response
и всё, что происходит между call и response, хоть с твоим реквестом, хоть с аксиосом, будет неявно до тех пор, пока не полезешь в кишки
user -> call -> response
и всё, что происходит между call и response, хоть с твоим реквестом, хоть с аксиосом, будет неявно до тех пор, пока не полезешь в кишки
проблема именно в процессе полезания в кишки
c
в моем случае код модифицирующий запрос
лежит буквально в обертке
его крайне легко найти
лежит буквально в обертке
его крайне легко найти
c
удачи найти все использования axios.interceptors.response.use в проекте
c
и вообще, надо вспомнить, что интерсепторы есть
и используются в проекте
и сколько их
и написал ли кто поверх них абстракцию
и используются в проекте
и сколько их
и написал ли кто поверх них абстракцию
c
посмотри на разницу в трудозатратах:
1. посмотреть исходник обертки
2. найти все интерсепторы, понять время их применения, изучить исходник каждого, сложить их эффекты в голове
1. посмотреть исходник обертки
2. найти все интерсепторы, понять время их применения, изучить исходник каждого, сложить их эффекты в голове