Oprócz świetnych wyjaśnień echonax
i Nishchit Dhanani
chcę dodać, że naprawdę nienawidzę populacji składników module.id
. Zwłaszcza, jeśli masz wsparcie dla kompilacji AoT (Ahead-of-Time) i dla realistycznego projektu jest to cel, do którego powinieneś dążyć, nie ma miejsca na coś takiego module.id
w metadanych komponentów.
Z Dokumentów :
Aplikacje kompilowane w JiT, które używają modułu SystemJS
ładującego i adresów URL zależnych od komponentu, muszą ustawić @Component.moduleId
właściwość na module.id
. Obiekt modułu jest niezdefiniowany, gdy uruchomiona zostanie aplikacja skompilowana z użyciem AoT. Aplikacja kończy się niepowodzeniem z błędem odniesienia zerowym, chyba że przypisasz globalną wartość modułu w pliku index.html w następujący sposób:
<script>window.module = 'aot';</script>
Myślę, że posiadanie tej linii w produkcyjnej wersji index.html
pliku jest absolutnie niedopuszczalne!
Dlatego celem jest posiadanie kompilacji JiT (Just-in-Time) do programowania i obsługa AoT w produkcji z następującą definicją metadanych komponentów: (bez moduleId: module.id
wiersza)
@Component({
selector: 'my-component',
templateUrl: 'my.component.html', <- relative to the components current path
styleUrls: ['my.component.css'] <- relative to the components current path
})
Jednocześnie chciałbym umieszczać style, my.component.css
pliki podobne i szablony, takie jak my.component.html
względemmy.component.ts
ścieżek plików składowych .
Aby to wszystko osiągnąć, rozwiązaniem, którego używam, jest hostowanie serwera WWW (serwer Lite lub synchronizacja przeglądarki) podczas fazy programowania z wielu źródeł katalogów!
bs-config.json
:
{
"port": 8000,
"server": ["app", "."]
}
Proszę wziąć szczegóły tej odpowiedzi dla mnie.
Przykładowy projekt szybkiego startu kątowego 2, który opiera się na tym podejściu, znajduje się tutaj .