HTTP-Client
Zuerst wird erklärt, wie man den Core-Client direkt verwendet, gefolgt von einem Beispiel für die optionale Integration des gemeinsamen HTTP-Adapters, den der automatisch generierte Service verwendet.
Direkte Verwendung des Core-Clients
Die Paths, die in createHttpClient<Paths>() injiziert werden, sind die Anfrageverträge. URL und Methode stammen aus dem Schlüssel von Paths, queryString und pathVariable aus den Parametern, und der Body wird aus requestBody abgeleitet.
Der Antworttyp wird von dem R bestimmt, das der Aufrufer in callApi<R>() angibt. Core leitet den Antworttyp nicht automatisch aus den OpenAPI-Antworten ab.
httpClient.ts
tsDie Antwortform kann pro API ausgewählt werden.
typed-rx-http zwingt nicht zur Verwendung von ResponseWrapper. Wenn die Serverantwort ein Wrapper ist, geben Sie den Wrapper-Typ als R an, andernfalls geben Sie den tatsächlichen Antworttyp direkt an.
Optional: Gemeinsamer Adapter + automatisch generierter Service
Die folgende Konfiguration von commonService ist keine zwingende Struktur des Core, sondern ein Projektintegrationsmuster, das versucht, Authentifizierung, SSR-Header und Cache-Richtlinien auf mehrere generierte Services gleichzeitig anzuwenden.
Was der Projekt-commonService tut
commonService ist keine spezielle Klassenbezeichnung, die von @byeolnaerim/typed-rx-http bereitgestellt wird, sondern eine benutzerdefinierte Datei, die im Projekt verwendet wird, um gemeinsame HTTP-Richtlinien an einem Ort zu bündeln. Der Dateiname ist frei und im folgenden Beispiel wird der tatsächliche Projektname rxjsHttpService.ts verwendet.
Um zu vermeiden, dass createHttpClient für jeden Bildschirm und jeden automatisch generierten Service wiederholt wird, wird callApi und callApiStream, die von dieser Datei erstellt wurden, als gemeinsamer Einstiegspunkt verwendet. Daher werden Änderungen an den Regeln für die Authentifizierung, die Übertragung von SSR-Headern, Cache und Fehlerbehandlung einmal vorgenommen und gelten für alle generierten Services.
Beginnen Sie mit dem gesamten Code von commonService/rxjsHttpService.
1. Minimale vollständige Version
Die Essenz des commonService ist der folgende Code. Erstellen Sie einmal den headerStore und den typisierten HTTP-Client, und exportieren Sie die generierte Dienstleistung, die callApi/callApiStream gemeinsam nutzt. uploadFile und createSSEObservable können ebenfalls im selben Client exponiert werden.
rxjsHttpService.ts
ts2. Next.js + Sitzungsauthentifizierung + erweiterte CSR/SSR-Cache
Unten ist ein vollständiges Projektbeispiel, das die Sitzungsauthentifizierung, SSR-Header und CSR/SSR-Cache zum gleichen gemeinsamen Adapter hinzufügt. Wenn das generierte Dienstprojekt den Cache-Wrapper importiert, wird diese Form zum Standard. Kopieren Sie es einfach und passen Sie setLogin-Import, ApiTypes und CacheNames-Position, Authentifizierungs-API-Pfad, Umgebungsvariablen und nicht autorisierte Pfade an Ihr Projekt an.
rxjsHttpService.ts
tsRolle nach Code-Struktur
paths
Typen von OpenAPI-Pfaden, die von createHttpClient und ServiceArguments verwendet werden, um URL, Methode, Pfadvariable, Abfrage und Body-Typ zu überprüfen.
headerStore
Speichert gemeinsame Header wie Content-Type und Authorization im Browser und teilt sie mit der Sitzungsauthentifizierung und RSocket-Verbindungen.
headersProvider
Gibt headerStore in CSR zurück und liest in SSR die Cookies und Authorization der aktuellen Anfrage, um für jede Anfrage unterschiedliche Header bereitzustellen.
service
Echter typisierter HTTP-Client mit Basis-URL, gemeinsamen Headern, Server-401-Verarbeitung und Standardfehlernachricht.
sessionAuth
Synchronisiert das Sitzungstoken vor der Anfrage und versucht bei 401 nach einem Refresh das ursprüngliche Observable einmal erneut; bei Fehlschlag wird der Logout-Prozess ausgeführt.
callApi / callApiStream
Gemeinsame Funktionen, die von automatisch generierten allgemeinen REST-Diensten und NDJSON-Stream-Diensten importiert werden. Beide geben ein RxJS Observable zurück.
callApiClientCache / callApiServerCache
Cache-Wrapper, der im Browser den CSR-Cache verwendet und auf dem Server den SSR-Cache von @byeolnaerim/typed-rx-http/next dynamisch lädt.
Art und Weise, wie es mit dem automatisch generierten Dienst verbunden ist.
Der Generator berechnet den relativen Pfad der commonServiceFile und fügt jedem Dienst einen Import hinzu. Der Bildschirm importiert die generierten Funktionen, ohne die öffentlichen Dateien direkt aufzurufen, und die generierte Funktion übergibt den Pfad, die Parameter und den Body an callApi als pathVariable, queryString und body von ServiceArguments.
generateSwagger.cjs
jsEine Antwort ist firstValueFrom
REST-APIs, die einmal antworten und enden, wie Suchen, Speichern, Löschen, können das generierte Observableempfangen werden. Dies ist derzeit die am häufigsten verwendete Methode im NPL-Projekt.erhalten, sodass sie auch in bestehenden asynchronen Funktionen natürlich verwendet werden können.
BusinessSearchPage.tsx
tsxAuf dem Bildschirm werden paramsnur angezeigt, aber im generierten Service sind URL, HTTP-Methode und Antworttyp enthalten. Abfrageparameter werden immer{ params: { ... } }übergeben.
Mehrere Antworten abonnieren
Anfragen, bei denen mehrere Werte wie der Fortschritt oder RSocket-Stream ankommen,firstValueFromwerden empfangen, und die Abonnierung wird aufgehoben, wenn die Komponente verschwindet.
BatchJobPage.tsx
tsxWenn Sie callApi direkt verwenden
In Projekten, die keinen Dienstgenerator verwenden oder vor der Erstellung temporäre Endpunkte überprüfen, kann die callApi des öffentlichen Dienstes direkt aufgerufen werden. Der Anfragetyp wird in den Pfaden überprüft und der Antworttyp wird vom Aufrufer generisch angegeben.