مكتبتي

شريط جانبي متعدد الجذور

flex-layout

  • Getting Started

  • Guides

  • Reference

typed-rx-http

  • Getting Started

  • Guides

  • Reference

global-rx-state

  • Getting Started

  • Guides

  • Reference

webflux-fe-dev-assistant

reactive-mongo-dsl

بدء سريع

عميل HTTP آمن من نوع RxJS لـ TypeScript + (اختياري) محول Next.js/RSocket.


الميزات الأساسية
  • ضمان استقرار نوع route (الطلب) عن طريق حقن نوع Paths بأسلوب OpenAPI المستمد من Swagger/OpenAPI / AsyncAPI / مخططات مخصصة.
  • تقوم جميع واجهات برمجة التطبيقات بإرجاع RxJS Observable.
  • النواة مستقلة عن الإطار (لا تعتمد على Next.js)
  • الميزات الخاصة بـ Next.js مفصولة في نقطة الدخول @byeolnaerim/typed-rx-http/next → تحتاج Next.js فقط عند استيراد /next.
  • الميزات الخاصة بـ RSocket مفصولة في نقطة الدخول @byeolnaerim/typed-rx-http/rsocket → تحتاج حزمة RSocket فقط عند استيراد /rsocket.
التثبيت
npm
bash
نقطة الدخول
Core (مستقل عن الإطار)
ts
محول Next.js (اختياري)
ts

لا تستورد /next في المشاريع التي لا تستخدم Next.js.

محول RSocket (اختياري)

قم بتثبيت حزمة peer فقط في المشاريع التي تستخدم RSocket.

bash
ts

لا تستورد /rsocket في المشاريع التي لا تستخدم RSocket.

كيفية استخدام النواة

1) إعداد نوع Paths (عادةً ما يكون OpenAPI paths)

Paths في createHttpClient<Paths>() تعبر عن "مواصفات الطلب (route)". تُسمى عادةً paths في الوثيقة، لكن ليس من الضروري أن تكون OpenAPI/Swagger، أو أن يكون اسمها paths.

ومع ذلك، تستخدم النواة داخليًا قيد OpenApiPathsLike، لذا يجب أن تكون Paths مشابهة للشكل أدناه مثل OpenAPI paths.

  • المفتاح الأعلى: سلسلة مسار URL (مثل: "/users/{id}")
  • المفتاح الفرعي: طريقة HTTP (get/post/put/delete/patch …)
  • يوجد داخل كل طريقة حقول مثل parameters.query/path/header/cookie وrequestBody وresponses (أو never)

تشير النواة بشكل أساسي إلى الحقول أدناه لتكوين نوع ServiceArguments.

  • url: keyof Paths
  • method: keyof Paths[url]
  • queryString: parameters.query
  • pathVariable: parameters.path
  • body: requestBody

مثال: مخرجات openapi-typescript عادة ما تكون وفقًا للمواصفات التالية (بعض الاختصارات).

ts
ts
2) إنشاء HeaderStore

HeaderStore هو مخزن بسيط في الذاكرة لإدارة الرؤوس الأساسية في CSR.

ts
3) إنشاء عميل HTTP
  • headerStore اختياري، ولكن يُوصى بإضافته إذا كنت ترغب في استخدام الرؤوس الأساسية/مصادقة الجلسة في CSR.
  • headersProvider يُستخدم عندما تحتاج إلى حساب الرؤوس لكل طلب مثل SSR/تعدد المستأجرين.
ts
4) استدعاء API (آمن من حيث النوع)

نوع الطلب (url/method/pathVariable/queryString/body) يتم تحديده من النوع الذي تم حقنه في createHttpClient<Paths>() (عادةً ما يكون مسارات OpenAPI). نوع الاستجابة يتم اختياره من قبل المستدعي في callApi<R>() كـ R جنريك (النواة لا تستنتج تلقائيًا من responses).

ts
تغليف الاستجابة (ResponseWrapper) — اختياري

هذه المكتبة لا تفرض تغليف الاستجابة. يمكنك اختيار شكل الاستجابة بشكل جنريك لكل API.

استجابة مغلفة
ts
استجابة غير مغلفة
ts
البث (NDJSON)

عندما يقدم الخادم NDJSON (JSON واحد في كل سطر)، استخدم callApiStream. إذا لم يكن هناك رأس Accept، يتم تعيين application/x-ndjson كقيمة افتراضية.

ts
ذاكرة التخزين المؤقت CSR (ذاكرة التخزين المؤقت للعميل)

الوظائف التي يوفرها createCsrCache<CacheName>():

  • callApiCsrCache(callApiFn, serviceArgs, cacheOptions)
  • removeCsrCache(cacheName) — يدعم جميع أسماء نوع الذاكرة + السلاسل النصية.
ts
ملحق مصادقة قائم على الجلسة (اختياري)

createSessionAuth يفصل منطق مصادقة الجلسة عن النواة بحيث يمكن إضافته وإزالته كخيار.

العمليات:

  • الحفاظ على Authorization في headerStore
  • مزامنة الرمز باستخدام ensureToken$() (/api/auth/token)
  • عند حدوث 401، حاول التحديث مرة واحدة (/api/auth/token/refresh) ثم أعد محاولة الطلب الأصلي.
  • عند فشل التحديث، قم بتسجيل الخروج (/api/auth/logout) ثم نقل الخطأ.
  • تغيير حالة تسجيل الدخول يتم معالجته خارجيًا بواسطة onLoginChange callback.
ts

إذا كنت بحاجة فقط لمزامنة الرمز بدون تحديث/إعادة محاولة:

ts
معالجة الأخطاء

إذا لم يكن 2xx، يتم رمي HttpResponseError (بما في ذلك status و response و args و data).

التوافق مع الأنظمة القديمة: إذا كان جسم الخطأ على شكل { resultType: ... }، يتم رمي هذا الكائن كما هو.

ts
محول Next.js (/next)
redirectToUnauthorizedOnServer401

redirectToUnauthorizedOnServer401 هو التنفيذ الافتراضي (دالة مساعدة) الذي يقوم بإعادة التوجيه عند حدوث 401 في بيئة SSR لـ Next.js (App Router).

ts

قواعد التشغيل (ثابتة):

  • وجهة إعادة التوجيه: /unauthorized
  • queryString: redirect_uri=<الصفحة الحالية> + logout=true
  • يتم قراءة الصفحة الحالية من رأس x-page-url (إذا لم يكن موجودًا، يتم استخدام /)

أي، استخدم قواعد المسار/الاستعلام أعلاه كما هي فقط عندما تتطابق مع المشروع. إذا كان المسار مختلفًا أو كانت قواعد الاستعلام مختلفة، يمكنك تنفيذ onServer401 مباشرة كما هو موضح أدناه.

ts
callApiSsrCache

مساعد ذاكرة التخزين المؤقت SSR القائم على next/cache(unstable_cache) من Next.

  • GET + cacheTime > 0 → force-cache + revalidate
  • بخلاف ذلك → no-store
  • حقن ملفات تعريف الارتباط / التفويض لكل طلب باستخدام headersProvider
  • عند حدوث 401، يتم تنفيذ onServer401 إذا كان موجودًا (عادةً redirect())
ts
مثال تكامل Next.js: الكود الكامل لمشروع rxjsHttpService/commonService

ملف rxjsHttpService.ts أدناه هو محول HTTP العام للمشروع المشار إليه في مثال المولد لاحقًا. هذا ليس ملفًا تم إنشاؤه بواسطة المكتبة، بل يتم إدارته مباشرة من قبل المشروع، ويصدر core client + session auth + CSR cache + SSR cache helper في مكان واحد. أدناه هو الكود الكامل.

rxjsHttpService.ts
ts
مرجع API (core)
createHttpClient<Paths>(options)

الإرجاع:

  • callApi<R>(args): Observable<R>
  • callApiStream<RChunk>(args): Observable<RChunk>
  • uploadFile({ file, url, ifNoneMatch?, headers? }): Observable<Response>
  • createSSEObservable<R>(args): Observable<R>

الخيارات:

  • baseUrl: string
  • headerStore?: HeaderStore
  • headersProvider?: () => Record<string, string> | Promise<Record<string, string>>
  • dropAuthWhenCacheControl?: boolean (القيمة الافتراضية: true)
  • onServer401?: () => void | Promise<void>
createCsrCache&lt;CacheName&gt;()

get(), set(), merge(), remove(), clear()

createCsrCache<CacheName>()
  • callApiCsrCache(callApiFn, serviceArgs, cacheForService)
  • removeCsrCache(cacheName) (النوع + السلسلة)
تصديرات Stream & utility
  • withSessionAuth(), withEnsureToken()
  • ensureToken$(), refreshToken$(), logout$()
متطلبات وقت التشغيل
  • استخدام fetch / Response API (rxjs/fetch)
  • البث (NDJSON) يتطلب ReadableStream + TextDecoder
  • SSE يتطلب EventSource

يتوفر في معظم المتصفحات الحديثة وبيئة تشغيل Next.js. قد تحتاج بيئات تشغيل Node المخصصة إلى polyfill.

Auto Node Script: إنشاء كود OpenAPI/Swagger (اختياري)

تقدم هذه الحزمة، بالإضافة إلى عميل HTTP في وقت التشغيل، سكربت Node لإنشاء كود النوع/الخدمة من JSON OpenAPI/Swagger. هذا السكربت هو ميزة اختيارية.

لا يحتاج المستخدمون العاديون لـ @byeolnaerim/typed-rx-http، /next، /rsocket إلى تشغيل هذا السكربت، ولا يحتاجون إلى تثبيت openapi-typescript.

ts
عزل الاعتماديات

تتطلب إنشاء أنواع OpenAPI استخدام openapi-typescript CLI. لكن هذه الحزمة لا تضيف openapi-typescript إلى الاعتماديات العامة.

تستخدم مكتبة @byeolnaerim/typed-rx-http نفسها TypeScript 6.0.3 كـ devDependencies.typescript. تحافظ نقاط الدخول إلى typed-rx-http، /next، /rsocket وبناء المكتبة على هذا المعيار TypeScript 6.0.3.

ومع ذلك، قد يتطلب openapi-typescript إصدارًا معينًا من TypeScript 5.x، لذا يتم تشغيل سكربت OpenAPI auto node فقط في بيئة تنفيذ مؤقتة منفصلة مع openapi-typescript و [email protected]. لا تغير هذه البيئة المؤقتة devDependencies.typescript 6.0.3 للمكتبة، ولا تستخدم إصدار typescript أو openapi-typescript المثبت في مشروع المستخدم.

القيمة الافتراضية هي إنشاء وتنفيذ الأوامر أدناه فقط في وقت تشغيل السكربت التلقائي.

bash

لذا، لا تتغير طريقة الاستخدام نفسها. يمكنك استدعاء سكربت auto node كما هو معتاد، وسيتم استخدام بيئة TypeScript 5.9.3 المعزولة فقط في مرحلة إنشاء نوع OpenAPI. المستخدمون الذين لا يستخدمون السكربت التلقائي غير مقيدين بـ openapi-typescript أو TypeScript 5.9.3.

إذا لزم الأمر، يمكنك تثبيت الأوامر مباشرة باستخدام openApiTypescriptCommand.

ts

أو يمكنك تغيير إصدار الحزمة التي تشكل الأوامر الأساسية فقط.

ts
الملفات التي يتم إنشاؤها

الإعدادات الافتراضية تنشئ الملفات أدناه.

text

apiUnionArrays.ts ينشئ مصفوفات ثابتة للـ enum في مخطط OpenAPI بالإضافة إلى enum للمعلمات في الاستعلام، المسار، الرأس، وملف تعريف الكوكيز. كما يعالج items.enum لمعاملات الاستعلام.

مراقبة EventStream
ts
طلب HTTP لمرة واحدة
ts
إنشاء من ملف محلي
ts

مثال على دمج مشروع قائم: WebFlux + إنشاء تلقائي لـ Swagger

من هنا، هو مثال على دمج مشروع يستخدم Swagger الخلفي وخدمة الإنشاء التلقائي معًا. يمكن استخدام طريقة الاستخدام الأساسية والميزات الاختيارية أعلاه باستخدام typed-rx-http فقط، بينما يتم تطبيق التدفق أدناه في مشروع يستخدم إنشاء الخدمة التلقائي القائم على Swagger.

1. كتابة نقطة نهاية REST في الخلفية.

يتم كتابة كود الخلفية كما هو معتاد. في هذا المثال، يتم استلام الاسم كمتغير مسار، والرسالة كمعامل استعلام. Monoويتم الرد.

TypedRxHttpExampleRouter.java
java
2. إنشاء خدمة الواجهة الأمامية من Swagger.

يتم استلامها من الخلفية لإنشاء ملف النوع والخدمة. يمكن استدعاء هذه العملية مرة واحدة عند تشغيل خادم التطوير أو ربطها بسكربت المراقبة. swagger.json3. إرسال الطلب باستخدام الوظيفة التي تم إنشاؤها.

generateSwagger.cjs
js
يمكنك تغييرها أدناه.

يمكنك الضغط على الزر لفتح شاشة التنفيذ على اليمين. بعد تغيير القيم، جرب الضغط على زر الطلب. النتيجةو الجزء المرئي في المشروع الفعلي.كود الواجهة الأمامية لا يحتوي كود الشاشة على سلسلة URL أو واجهة استجابة. كلاهما موجود في Swagger.كود الخلفية

TypedRxHttpRequestExample.tsx
tsx
© 2026 بيولناريم. جميع الحقوق محفوظة.مقدمةسياسة معالجة المعلومات الشخصية