С
да, в одной
Это очень странно
Size: a a a
2020 May 03
S
Это очень странно
все они напрямую и функционально связаны с user
S
/user/account/settings
KW
Подскажите, пожалуйста, как это пофиксить. Зависимость установлена и модуль прописан но проект не хочет собираться
AO
/user/account/settings
ну вот у меня сейчас в одном большом приложении примерно так и сделано, и вот эта вложенность иногда напрягает, потому что местами не ограничивается двумя или тремя уровнями. почему я и заинтересовался вопросом структуры. есть определённые минусы в текущем подходе
AT
https://stackblitz.com/edit/angular-r5m7mt
вопрос по использованию ng-template
вопрос по использованию ng-template
каким образом в шаблон передать информацию о типе переменной let-order
AT
когда я использую сокращенную форму редактор понимает тип и предлагает мне на выбор дополнить существующие поля. в данном случае n1
AT
как добиться чтоб и ng-template внутри предлагал то же
S
ну вот у меня сейчас в одном большом приложении примерно так и сделано, и вот эта вложенность иногда напрягает, потому что местами не ограничивается двумя или тремя уровнями. почему я и заинтересовался вопросом структуры. есть определённые минусы в текущем подходе
Правильно сделано
S
У юзер есть аккаунт а у аккаунта есть настройки
S
Не будет аккаунта не будет и настроек аккаунта
AO
Правильно сделано
ок, я понял, тогда в целом буду придерживаться такого подхода. спасибо большое
VS
AO
@dersizes хотя всё равно некоторые вопросы остаются. если нельзя делать папки components, services и т.п., то как быть с большими модулями? если создаётся кастомная таблица и разбивается на компоненты, и их может быть 5-6, плюс несколько сервисов для неё. допустим, один занимается парсингом данных с бэка, другой работает с данными на фронте, третий отправляет всё обратно. представьте, что так надо, иначе файлы огромные будут)
таким образом в модуле получается каша из всего, что в нём есть. а если таки создавать папки components и т.д., то тогда папка с вложенным модулем визуально теряется среди остальных, потому что у неё произвольное имя. можно решить это, поместив вложенные модули в папку modules рядом с components, но блин
таким образом в модуле получается каша из всего, что в нём есть. а если таки создавать папки components и т.д., то тогда папка с вложенным модулем визуально теряется среди остальных, потому что у неё произвольное имя. можно решить это, поместив вложенные модули в папку modules рядом с components, но блин
S
@dersizes хотя всё равно некоторые вопросы остаются. если нельзя делать папки components, services и т.п., то как быть с большими модулями? если создаётся кастомная таблица и разбивается на компоненты, и их может быть 5-6, плюс несколько сервисов для неё. допустим, один занимается парсингом данных с бэка, другой работает с данными на фронте, третий отправляет всё обратно. представьте, что так надо, иначе файлы огромные будут)
таким образом в модуле получается каша из всего, что в нём есть. а если таки создавать папки components и т.д., то тогда папка с вложенным модулем визуально теряется среди остальных, потому что у неё произвольное имя. можно решить это, поместив вложенные модули в папку modules рядом с components, но блин
таким образом в модуле получается каша из всего, что в нём есть. а если таки создавать папки components и т.д., то тогда папка с вложенным модулем визуально теряется среди остальных, потому что у неё произвольное имя. можно решить это, поместив вложенные модули в папку modules рядом с components, но блин
я ничего не понял что ты придумал
есть какой то конкретный пример?
есть какой то конкретный пример?
AO
я ничего не понял что ты придумал
есть какой то конкретный пример?
есть какой то конкретный пример?
сложные модули могут превратиться во что-то подобное
если делить на папки, то большая вложенность получается. у some-module тоже ведь могут быть свои компоненты, сервисы и т.д.
а если не делить на папки, то ещё хуже получается, наверно
если делить на папки, то большая вложенность получается. у some-module тоже ведь могут быть свои компоненты, сервисы и т.д.
а если не делить на папки, то ещё хуже получается, наверно
S
сложные модули могут превратиться во что-то подобное
если делить на папки, то большая вложенность получается. у some-module тоже ведь могут быть свои компоненты, сервисы и т.д.
а если не делить на папки, то ещё хуже получается, наверно
если делить на папки, то большая вложенность получается. у some-module тоже ведь могут быть свои компоненты, сервисы и т.д.
а если не делить на папки, то ещё хуже получается, наверно
все было хорошо пока все не стало плохо
AO
можно убрать папки и сделать так, и сейчас будет выглядеть опрятнее. но если добавятся пайпы, директивы и модели, а из some-module убрать "module", то получается каша