Dyrektywa AngularJS a obsługa vs kontroler


15

Zaraz zacznę wdrażać żądanie zmiany na wewnętrznej stronie internetowej mojej firmy, która sprawdzi kilka pól i podświetli je, jeśli będą zgodne z określonymi wytycznymi. Na przykład, jeśli data urodzenia przypada dzisiaj, pole to zostanie oznaczone, a podpowiedź powie „Życz im wszystkiego najlepszego!”.

Specyfikacje wymagają załadowania tego po zakończeniu renderowania reszty strony, więc nie zwiększy to czasu ładowania. Ponieważ jestem nowy w angularJS, nie jestem pewien, jak należy to zrobić.

Problemy:

Ponieważ obejmuje to dodawanie ramek i obrazów oraz atrybutów tytułu (manipulacja DOM), wydaje się, że powinienem stosować dyrektywę.

Nie będzie to jednak wielokrotnego użytku lub „krótkie”, jak wydaje się większość dyrektyw.

Połowa danych, które muszę sprawdzić, zostanie zwrócona w pierwotnym wywołaniu przy ładowaniu strony, więc chciałbym to zapisać i nie marnować kolejnego połączenia, aby je odzyskać, co sprawia, że ​​myślę, że usługa byłaby miła do przechowywania wszystkich tych danych.

Wiem, jak to wszystko zrobić w kontrolerze, ale to zły zły kod: P

Jakieś pomysły na najlepszy sposób, w jaki można to zrobić? Zasadniczo będę potrzebować wywołania http, aby sprawdzić wszystkie dane, które zwrócą obiekt z wartościami bool dla każdego typu „Call Out”, który muszę zrobić. Następnie przejdę przez tę listę i jeśli wartość jest prawdą, dodaj ramkę, obraz i tekst podpowiedzi.

Nie jestem pewien, czy to pytanie jest wystarczająco jasne, więc jeśli chcesz, żebym dodał jakieś szczegóły, zapytaj. Dziękuję Ci!


1
Dlaczego musisz użyć tylko 1 z 3? Wydaje mi się, że najlepszym rozwiązaniem byłoby połączenie przynajmniej dyrektyw i serwisu / kontrolera.
Pete

Kombinacja też jest w porządku, jestem tylko zdezorientowany, jak to powinno działać.
Bobo

Przepraszamy, to jest w komentarzach, nie ma czasu na poprawną odpowiedź. Twoje wezwanie do wykonania danych prawdopodobnie przejdzie do usługi. Tę usługę należy wprowadzić do kontrolera. Jeśli potrzebujesz podać logikę dla widoku tych danych, trafia ono do kontrolera. Wreszcie, twój widok powinien używać twoich dyrektyw, które mogą wykorzystywać dowolną logikę, którą mogłeś ujawnić w kontrolerze.
Pete

Odpowiedzi:


27

Masz rację, w grze jest wiele opcji.

Kontroler to dobre miejsce, aby zacząć pisać coś nowego pod kątem. Powiązanie kontrolera z fragmentem znaczników pozwala używać istniejącej biblioteki dyrektyw angular z istniejącymi usługami angular.

Po bardzo krótkim czasie życia z tym zdasz sobie sprawę, że twój kontroler stał się zbyt duży. Teraz czas na refaktoryzację. Oto ogólne wytyczne, których zwykle używam.

  • Kontrolery: kontrolery dołączają wartości / funkcje związane z zakresem $ i zarządzają nimi. Ostatecznie zakres $ zwykle silnie zależy od prezentacji . IE to model widoku.
  • Usługi: usługi mają tendencję do łączenia infrastruktury, zaplecza lub innych funkcji przeglądarki
  • Dyrektywy: dyrektywy umożliwiają integrację ze zdarzeniami / funkcjami DOM nieobsługiwanymi przez istniejące programy obsługi.

Więc będziesz chciał wypchnąć kod w jednym z trzech kierunków:

  1. Kod z mojego kontrolera jest naprawdę logicznie kolejną częścią danych / logiki prezentacji i powinien zostać podzielony na inny kontroler . Uwaga: podczas pracy z elementami na $ scope najlepiej jest posegregować części, za które odpowiedzialny jest każdy kontroler, do ich własnych obiektów w $ scope. Na przykład $ scope.creditCard. [Blah] dla jednego kontrolera vs $ scope.billingAddress. [Blah] dla innego kontrolera. Pomaga to zapobiec problemom z wykorzystaniem przez Angular prototypowego dziedziczenia w $ scope.

  2. Kod z mojego kontrolera to fragment infrastruktury aplikacji lub kod narzędziowy, który może wymagać udostępnienia za pośrednictwem aplikacji i powinien zostać podzielony na usługę

  3. Kod mojego kontrolera jest bardzo zaniepokojony prezentacją / organizacją DOM i dlatego powinien zostać podzielony na własną dyrektywę

Przykładem 1. może być obsługa wprowadzania / weryfikacji karty kredytowej osobno od reszty formularza płatności. Miałbyś sporo logiki karty kredytowej w kontrolerze oddzielnym od logiki pozwalającej użytkownikom na wprowadzanie adresów, więc byliby logicznie oddzielnymi kontrolerami.

Przykładem 2 może być przeniesienie części, która komunikuje się z usługą obsługi kart kredytowych, aby zaakceptować / odrzucić płatność. Innym przykładem może być moduł, który komunikuje się z backendem w celu obsługi interfejsu API tworzenia użytkowników.

Przykładem 3 może być stworzenie funkcji automatycznej zakładki, która przesuwa kursor między 4 polami edycji po wprowadzeniu 4 liczb dla karty kredytowej.

Podziel odpowiednio swoją aplikację.


To naprawdę pomogło mi zrozumieć więcej na temat kąta. Dziękuję bardzo :)
Bobo
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.