E
Если правильно понял - если ngOnDestroy нету он его создает с unsubscribe, так?
да
Size: a a a
2020 May 04
В
да
понял, спасибо )
OV
Всем привет.
Мб кто сталкивался - мне нужны headers из response.
response.headers в хроме возвращает все хидеры, я получаю все, что надо.
Но в сафари почему то response.headers получает только часть хидеров из всех.
При этом через devtools, все нужные мне хидеры в ответе присутствуют. Куда в сафари деваются остальные мне как-то не понятно
Мб кто сталкивался - мне нужны headers из response.
response.headers в хроме возвращает все хидеры, я получаю все, что надо.
Но в сафари почему то response.headers получает только часть хидеров из всех.
При этом через devtools, все нужные мне хидеры в ответе присутствуют. Куда в сафари деваются остальные мне как-то не понятно
S
Продолжая вчерашнюю тему, что думаете насчет такой имплементации clean architecture? https://medium.com/intive-developers/approach-to-clean-architecture-in-angular-applications-hands-on-35145ceadc98
Или лучше делать feature модули содержащие доменные области из каждого слоя? Но в этом случае мне кажется логика будет приколочена к определенной вьюхе и не очень гибко как то.
Или лучше делать feature модули содержащие доменные области из каждого слоя? Но в этом случае мне кажется логика будет приколочена к определенной вьюхе и не очень гибко как то.
AT
Да я опоздал на пати 😐
D
Всем привет.
Мб кто сталкивался - мне нужны headers из response.
response.headers в хроме возвращает все хидеры, я получаю все, что надо.
Но в сафари почему то response.headers получает только часть хидеров из всех.
При этом через devtools, все нужные мне хидеры в ответе присутствуют. Куда в сафари деваются остальные мне как-то не понятно
Мб кто сталкивался - мне нужны headers из response.
response.headers в хроме возвращает все хидеры, я получаю все, что надо.
Но в сафари почему то response.headers получает только часть хидеров из всех.
При этом через devtools, все нужные мне хидеры в ответе присутствуют. Куда в сафари деваются остальные мне как-то не понятно
Однажды у меня подобное было. ЕМНИП дело было в / в конце урла бэка (или в его отсутствии). В любом браузере кастомный хэдер проходил, кроме сафари. Попробуйте добавить/убрать слэш, вдруг поможет
OV
Однажды у меня подобное было. ЕМНИП дело было в / в конце урла бэка (или в его отсутствии). В любом браузере кастомный хэдер проходил, кроме сафари. Попробуйте добавить/убрать слэш, вдруг поможет
Хм. Интересно. Спасибо, попробую
D
Хм. Интересно. Спасибо, попробую
Точно так и было. Добавлял кастомный OTPtoken для некоторых запросов и только в сафари он отваливался. Даже проект вспомнил:)
S
Всем привет.
Мб кто сталкивался - мне нужны headers из response.
response.headers в хроме возвращает все хидеры, я получаю все, что надо.
Но в сафари почему то response.headers получает только часть хидеров из всех.
При этом через devtools, все нужные мне хидеры в ответе присутствуют. Куда в сафари деваются остальные мне как-то не понятно
Мб кто сталкивался - мне нужны headers из response.
response.headers в хроме возвращает все хидеры, я получаю все, что надо.
Но в сафари почему то response.headers получает только часть хидеров из всех.
При этом через devtools, все нужные мне хидеры в ответе присутствуют. Куда в сафари деваются остальные мне как-то не понятно
Access-Control-Allow-Headers
Access-Control-Expose-Headers
Мб
Access-Control-Expose-Headers
Мб
S
Да я опоздал на пати 😐
Какой то оверхед в статье кмк
S
> The architecture is “clean” and “screaming”: You can easily see what is going on in the project by looking at the usecase folder.
(нет)
(нет)
S
> Separation of concerns: Each application layer has its own responsibility, so functionality and framework logic is mixed up.
AT
Ну тут слой use cases говорит о том что делает приложение
AT
С первого взгляда мне тоже показался диким оверхедом, на каждую операцию отдельный use case класс. Но и в другим статьях по android например встречал такой же подход.
S
AT
Ну тут скорее наименование неудачное by name и тому подобное. Ну и по доменам можно разбить, User и в нем все use cases связанные с юзером и так далее
СП
<custom-component [(ngModel)]=“text”>
</custom-component>
custom-component:
<input> //можно ли как-то передать сюда байдинг из отцовской компоненты?
</custom-component>
custom-component:
<input> //можно ли как-то передать сюда байдинг из отцовской компоненты?
AT
В общем я понял вашу позицию, есть над чем подумать.
AT
> The architecture is “clean” and “screaming”: You can easily see what is going on in the project by looking at the usecase folder.
(нет)
(нет)
Вот тут приводят в пример юзекейсы как часть кричащей архитектуры (абзац Third, The “Screaming Architecture”) https://proandroiddev.com/why-you-need-use-cases-interactors-142e8a6fe576
V
юз-кейсы на картинке отделены от ui, который просто часть системы, просто плагин для i/o со стороны пользователя, чел в статье натянул сову на глобус и запили архитектуру системы внутри ее плагина
p.s. и я тоже ничего не понял из его архитектуры пока не прочитал всю статью
p.s. и я тоже ничего не понял из его архитектуры пока не прочитал всю статью