Strony internetowe AngularJS: pojedyncze aplikacje SPA/wielokrotne SPA/komponenty

Question

To pytanie od pewnego czasu mnie dręczy.

Jeśli tworzysz stronę internetową z wieloma funkcjami za pomocą Angular, czy lepiej zbudować ogromne SPA lub rozbić witrynę na funkcjonalne "aplikacje" i zbudować SPA dla każdej aplikacji?

Na przykład mamy witrynę społecznościową z kanałem powiadomień, profilem użytkownika, raportowaniem i grupami. Czy zbudowałbyś wszystkie te funkcje w jednym SPA, czy zbudowałbyś 4 różne SPA i pozwoliłbyś ramie zaplecza na właściwe SPA?

np.

www.mywebsite.foo #/profil/12345/Edukacja

vs

www.mywebsite.foo/profile/12345#/education

mi osobiście bardziej na korzyść Druga metoda, ponieważ zmniejsza rozmiar aplikacji, ale wymaga przeładowania strony podczas nawigacji między aplikacjami.

Answer 1

Mark Collings mówił o nic w swoim artykule:

https://markwillcollins.silvrback.com/7-things-i-wish-i-knew-about-angularjs

"3. Struktura jest krytyczny ..."

Sugeruje on, aby zaplanować każdą stronę przed startowych pracy.

A potem, jak sądzę, odkryjesz najlepsze podejście do swoich potrzeb.

Wolę izolować w małych serwisach, ponieważ nie widzę korzyści dzielenia małych fragmentów javascript w złożonej hierarchii obciążenia, przy użyciu metody require.js lub podobnego podejścia.

Answer 2

Tak więc, oto co się dowiedziałem i co zrobiłem:

Mój serwer ma domyślną trasę:

var express = require('express'); 
    var router = express.Router(); 

    ... 

    router.get('*', function(req, res) { 
    res.sendfile(path.resolve(__dirname + '/../../../build/index.html')); // Send index.html for HTML5Mode 
    }); 

    return router; 

więc mogę mieć wiele SPA na mojej stronie, bo po prostu wysłać inny html szablony dla nich. Aplikacja w stylu HTML5 będzie musiała wybrać domyślną aplikację, jak powyżej.

Co należy do jednego SPA?

Wszystkie stany, które są powiązane ze sobą w zakresie obsługi użytkownika. Skomponowanie stanu między aplikacjami będzie skomplikowane (np. Uwierzytelnianie). Oczywiście wszyscy mogą uzyskać dostęp do pełnego stanu serwera.

Kiedy to jest przydatne?

Jeśli masz makiety, które pokazują wyraźnie różne przypadki użycia, np. dwa rodzaje użytkowników z różnymi loginami. Lub dwa różne "miejsca", do których się zalogowali.

Co można zyskać?

• Jeśli jesteś „dashboard” aplikacja ładuje pęczek kodu graficznego, ale Twoja „Strona docelowa” Aplikacja nie potrzebuje go, można zrobić lepsze wrażenia dla użytkowników końcowych.
• Jeśli użytkownik jest inny, łatwiejsze jest przechowywanie różnych kodów w różnych miejscach.
• W moim przypadku istniała również usługa SEO, która wyświetlała szablony "strony docelowej" na serwerze.

Być może nie wiesz, czego naprawdę potrzebujesz, dopóki go nie wypróbujesz. Zalecam więc zbieranie wszystkiego, co zależy od logowania do tej samej aplikacji. I domyślna aplikacja powinna zawierać "anonimowy użytkownik".