Как получить модель в директиве?

Question

[vasIvas]

При инициализации модель делает запрос на сервер и получает данные. Эти данные должны быть распарсены в директиве чтобы собрать динамическое меню. Каким образом модель должна попасть в директиву? Если она должна попасть в директиву через контроллер директивы, то как она должна попасть в него? И я не однократно слышал что использовать ngRepeat в шаблоне директиве это плохо, так же как и иметь и контроллер и линк одновременно. По этому у меня взрывается мозг.

Answer 1

[Сергей Протько]

Эти данные должны быть распарсены в директиве чтобы собрать динамическое меню.

они должны быть распаршены в сервисе, то есть в вашей модели. А затем уже это дерево или что еще в контроллере может быть приведено к формату view.

Каким образом модель должна попасть в директиву?

class FooController {
    constructor(fooService) {
        this.fooService = fooService;
    }
}

return {
    controller: FooController,
    controllerAs: 'vm',
    link: function (scope, el, attr, ctrl) {
         
    }
}

либо заинджектить сервис в директиву.

Comments

[vasIvas]

Получается такая последовательность -
1. Сервер, который у нас модель, инжектится в контроллер NavMenuController.
2. NavMenuController подключается к директиве navMenuDirective.
3. В методе link из ссылки на контроллер получаем нужную data, controller.getData();
4. Без ng-repeat и прочего собираю меню в методе link.
5. Обработку нажатия пишу вручную без использования ng-click в методе link.

6. Собираю меню с помощью element ( JQLite ), шаблон в директиве выглядит так -
template: `<div id="button-grup"></div>`,

То есть по сути классическая web вариация mvc. Контроллер хранит ссылку на модель и по просьбе представления передает ему из неё (модели) данные, которые заранее подготовлены в модели-сервисе.

Правильно?

[Сергей Протько]

vasIvas:

1) сервер не модель, это поставщик данных, ваш persistence layer.
2) тип того, я обычно не рассматриваю контроллер директивы как отдельную сущность. Это просто контроллер директивы, я даже по разным файлам их не раскидываю ибо не вижу смысла - и не экспортирую его нигде.
3, 4, 5, 6) - тут как хотите, можете вручную, можете заюзать какую-нибудь директиву для отображения деревьев и т.д. Причем в этом случае link не нужен вовсе, данные подготовить можно в контроллере, он для этого и нужен. А потом передать во view.

Да, старый добрый MVC. Только меня трактовка смущает. view говорит контроллеру что что-то случилось, контроллер просит модель дать ему данных и конвертит его в формат который понимает view и собственно скармливает ему. То есть controller это переводчик, посредник, как и положено.

[vasIvas]

Сергей Протько: с первым пунктом опечатался, сервис. А что касается "старого доброго", то я желаю ему скорее зарыться рядом с флешем. Я не хочу в очередной раз спорить, так как понимаю, что Вы думаете о своем. Но я немного посмеиваюсь над Вами и остальными. Ведь если представить, что я делаю приложение на только на одном canvas, то с Вашей идеологией у меня и физика и эффекты и миллионы строк кода будет в контроллере.
Представления вообще не будет и будет очень маленькие модельки. Зато контроллеры будут такие, что просто можно будет сума сойти. Хотя по Вашему все логика представления в сервисы уйдет. Ну да ладно, игры все равно буду по своему :)

Но у меня к Вам другой вопрос, который у меня сейчас на первом месте стоит и по которому я вообще ничего не знаю. Как нужно работать с js-data + angularjs + ts?
Лично я пока не до конца решил, нужно ли оформлять "это" в сервисах или же создать модуль, который будет подключать js-data и иметь методы создания, точнее регистрации ресурсов и регистрации классов ресурсов. Это для того, чтобы классы не мешать с angularjs.

И дальше вообще у меня пустота. Вот например нужно ли описывать schema + валидация или же валидация не нужна и schema достаточно. Нужно ли в точности копировать структуру orm на сервере?
Пока наверное и этого будет достаточно. Хотя ещё - существует ли что-нибудь для загрузки и внедрения объектов, которые скармливаешь store.defineResource? Ведь эти объекты же можно описать в json и если что-то затем нужно изменить, то это проще будет сделать в конфиге чем лезть в код. Ведь это так делают?

Спасибо.

[Сергей Протько]

vasIvas: я так и не понимаю как по вашему это должно работать. В гемдеве обычно применяют ECS, и там все действительно на ивентах и так как вы хотите. Никто в зравом уме не пихает MVC в игрушки, там совершенно другие принципы. MVC же нужно для приложений, где не нужно реагировать на изменение состояния по 60 раз в секунду.

[Сергей Протько]

vasIvas: что до js-data, я не могу сказать вам что знаю как оно надо делать, есть разные варианты. Я обычно запихиваю это дело в сервисы-репозитории, которые инкапсулируют логику сохранения данных. Так я делаю свой код более изолированным, можно скажем в рамках одного репозитория хранить данные в webstorage а в другом через js-data данные сохранять/доставать. А вот нужно ли репозитории выносить в отдельный модуль я пока не решил. Мне нравится эта идея но с ней есть свою нюансы. В TS есть интерфейсы и можно в отдельном модулей хранить реализацию только. Я же большую часть времени работаю с ES2015 и как-то... там с этим сложнее. Пока я не замарачиваюсь, мне достаточно изоляции на уровне репозитория.

По поводу копирования структуры ORM на сервере - нет конечно, вы же работаете с API, а ресурсы в контексте HTTP это далеко не всегда сущности в базе или проекция таблиц. Чем меньше ваш клиент будет знать о реализации сервера тем лучше.

А вот shema + валидация - тут как бы как, валидация тут нужна если вы сущности на клиенте создаете, а не только загружаете. Я лично ею не пользуюсь. Как альтернатива схемам можно вместо json использовать protocol buffer, тогда и трафик будет экономиться и проблема с валидацией схемы отпадет.

По поводу загрузки в store.defineResource - чисто теоритически вы можете через import json загрузить. Я думал об этом, правда в контексте кодогенерации. Но пока руки не дошли. Если у меня этот json не будет генерироваться из apiblueprint например то смысла в нем мало для меня лично.