این مقاله خلاصه ارائه
“React Native و Web همزیستی – رویکرد دیگر”
Seonkyu Kang ، توسعه دهنده در ویرایش
در مقاله قبلی ، ما در مورد ارتباطات بومی وب و روشهای حل آنها ، مشکلات پیش آمده و واکنش های بومی را مورد بررسی قرار دادیم. در این مقاله ، من فرایند حل موارد واقعی را با استفاده از مطالب از مقاله قبلی و هماهنگ سازی نوع امنیت و وب که در این فرآیند مشاهده می شود ، معرفی می کنم.
حل موارد واقعی
اکنون ما می توانیم به طور مؤثرتر مشکلات موجود در موارد دنیای واقعی را برطرف کنیم. هنگامی که ما این شرط را دریافت کردیم که “کلیک کردن روی یک محصول در WebView باید یک صفحه نمایش بومی یا یک صفحه وب موجود را نشان دهد” ، ما قبلاً مجبور بودیم کد را با فرض اجرای موفقیت آمیز بنویسیم و به صورت دستی همه موارد لبه را اداره کنیم ، اما اکنون ابزارهای مختلفی را تهیه کرده ایم. بنابراین ، من فکر کردم که ما می توانیم عمداً باعث خرابی ها و عدم موفقیت شویم.
تصویر زیر کد مورد واقعی قبلی را نشان می دهد. در این پل ، حرکت کنید که صفحه های React Native را از وب فراخوانی می کند ، در ThrowonError قرار می گیرد. هنگامی که Navigate Fails انجام شد ، وب نیز خطایی را به وجود می آورد و امکان رسیدگی به خطای یکپارچه را از طریق بلوک های گرفتن فراهم می کند. بنابراین هنگام حرکت به صفحه نمایش ProductDetail از طریق این Bridge Navigate ، اگر یک صفحه نمایش موجود باشد ، به خوبی حرکت می کند و اگر اینگونه نباشد ، می تواند از طریق Catch به صفحه میراث نسخه قدیمی حرکت کند.
بگذارید خلاصه کنم که چگونه ما مشکلات را با رویکرد موجود حل کردیم.
پدیده ای که منطق پیچیده در آن متمرکز است از طریق مدیریت روش به روش قابل حل است. پیش از این ، هنگام افزودن ویژگی ها ، ما مجبور شدیم توابع ارتباطی تکراری را از هر دو طرف بنویسیم ، اما با تولید خودکار توابع ارتباطی ، ما فقط باید آنها را در React Native حفظ کنیم. همچنین ، مشکل مهم ارتباطات یک طرفه با تغییر به یک ساختار وعده و در نهایت ، در مورد مسائل سازگاری عقب مانده ، حل شد ، در حالی که ما نتوانستیم همه چیز را حل کنیم ، ما توانستیم با استفاده از برنامه های کاربردی که از عدم موفقیت برخوردار هستند ، مسئله را کاهش دهیم.
ایمنی تایپ
آنچه اکنون معرفی خواهم کرد مربوط به “نوع ایمنی” است که من هنگام ایجاد یک کتابخانه از طریق این فرآیند ، مهم را در نظر گرفتم. بیایید به طور خلاصه بررسی کنیم که چرا ایمنی نوع ، که اغلب در اکوسیستم Typescript ذکر شده است ، ضروری است.
چرا نوع ایمنی مورد نیاز است: عدم تطابق نوع
یکی از دلایلی که ایمنی نوع مورد نیاز است عدم تطابق نوع است. هنگامی که پروژه های جلو و پس زمینه به طور مستقل وجود دارند ، آنها به طور کلی نمی توانند در مورد یکدیگر بدانند. هنگامی که جلوی API را به پس زمینه فرا می خواند ، نمی تواند انواع پاسخ های API را بشناسد ، بنابراین انواع باید به طور جداگانه تعریف شوند.
با این حال ، هنگام تعریف انواع به طور جداگانه ، اشتباهات رخ می دهد و به طور طبیعی عدم تطابق نوع اتفاق می افتد. به همین ترتیب ، اگر React Native را به عنوان پس زمینه و WebView به عنوان جلوی آن در نظر بگیریم ، عدم تطابق نوع اتفاق می افتد.
بیایید به این نوع عدم تطابق در کد نگاه کنیم. همانطور که در زیر نشان داده شده است ، لبه ها دارای مجموعه ای از اشیاء متشکل از گره و شناسه گره مربوطه هستند. از طریق این پاسخ ، انواع پاسخ ها مطابق کد نمونه در سمت راست تعریف می شوند. از آنجا که انواع به طور عادی وجود دارد ، ما انتظار داریم که بدون مشکل کار کند.
اما اگر تهی وارد مقدار شناسه شود چه اتفاقی می افتد؟ احتمالاً رندر به درستی کار نمی کند و خطاهای زمان اجرا همانطور که در کد سمت چپ زیر نشان داده شده است ، رخ می دهد. هنگامی که چنین خطاهای نوع رخ می دهد ، ابتدا باید استثنائات تهی را از طریق زنجیره ای اختیاری انجام دهیم و مشکل را حل کنیم.
تلاش برای حل عدم تطابق نوع
با طی کردن این فرآیند ، من فکر کردم که انواع نوشته شده توسط انسان ها نمی توانند 100 ٪ اعتماد داشته باشند. اگر چنین شرایط عدم تطابق به طور مکرر اتفاق بیفتد ، TypeScript می تواند هدف خود را از دست بدهد. من فکر می کنم بزرگترین هدف از TypeScript کشف اشکالات از قبل در مرحله کامپایل است. هنگامی که ما مرتباً با عدم تطابق نوع روبرو می شویم ، موقعیت هایی که انواع آنها را نادیده می گیریم و اغلب توسعه می یابیم ، که باعث می شود TypeScript هدف خود را از دست بدهد.
با این حال ، اکوسیستم TypeScript بسیار بزرگ است ، بنابراین تلاش های زیادی برای حل این عدم تطابق نوع وجود دارد. در API های REST ، ما می توانیم از طریق OpenAPI Generator Swagger را به TypeScript تبدیل کنیم. در GraphQL ، می توانیم طرحواره ها را از طریق GraphQL-Dodegen به Typescript تبدیل کنیم.
این ابزارها نیز به اندازه کافی عالی هستند ، اما Swagger نیز شامل لمس انسان است که در نهایت می تواند منجر به اشتباهاتی مانند عدم تطابق نوع شود. اگر انواع نادرست نوشته شده در Swagger به TypeScript تبدیل شوند ، این همچنین می تواند منجر به عدم تطابق نوع شود.
تعریف مستقیم انواع: استنباط را تایپ کنید
برای حل این مشکل ، تصمیم گرفتم انواع را مستقیماً تعریف نکنم. به طور دقیق تر ، من تصمیم گرفتم که به طور فعال از استنتاج نوع استفاده کنم. بگذارید در هنگام ایجاد کتابخانه از طریق نمونه های ساده ، به مفهوم نوع استنباط نوع من برای ایمنی نوع استفاده کنم.
نوع
هنگام اعلام روشهای بومی در پل ، به جای تعریف دستی رابط ها ، به این پل اجازه دادم که انواع را با استفاده از نوعف استنباط کند. مانند این ، با کمک کامپایلر ، می توانیم انواع مختلفی را استنباط کنیم و اگر این را به خوبی به وب ارسال کنیم ، انواع دریافت شده در وب می تواند به عنوان کد عادی در نظر گرفته شده توسط طرف بومی منعکس شود.
کلیدی
در مرحله بعد ، ما می توانیم با استفاده از کلمات کلیدی ساده مانند KeyOF ، تجربه توسعه دهنده را بهبود بخشیم. همانطور که در Hasmethod در تصویر زیر نشان داده شده است ، می توان انواع را از طریق KeyOF استنباط کرد. با کمک Keyof ، می توانیم نوع موجود را تعیین و استفاده کنیم.
عمومی
آنچه من فکر می کنم مهمترین استنباط از نوع است ، عمومی است. عملکرد پل در زیر توابع به نام مشترک و GetState را برمی گرداند. و من یک شیء عمومی را به عنوان نوع پل اعلام کردم. بنابراین ، اگر مقداری مانند 1234 به این پل منتقل شود ، خطای نوع ایجاد می کند زیرا این یک شی نیست. از طرف دیگر ، اگر یک شیء در اینجا وارد شود ، می توان انواع مختلفی را تکمیل کرد.
مهمترین بخش محتوای قبلی تکمیل انواع از طریق ورودی است. همانطور که در زیر نشان داده شده است ، هنگام استفاده از استفاده از Query Tanstack ، اگر بازدهی را از عملکرد پرس و جو دریافت می کنید ، می توانید داده ها را بر اساس مقدار بازگشت تکمیل کنید. به نظر می رسد کد ساده است ، اما از نظر داخلی این وضعیتی است که همه نوع از طریق ورودی از طریق فرآیندهای استنتاج نوع تکمیل می شوند.
جمله موجود در تصویر زیر همان چیزی است که نگهدار Query Tanstack گفت. با نگاهی به این ، اگر از نوع استنتاج استفاده می کنید ، به نظر می رسد هنگام نگاه کردن به کد از JavaScript استفاده می کنید ، اما در واقع می توانید از آن استفاده کنید که همه نوع ایمن است. این امر به این دلیل است که اگرچه UseQuery رابط جداگانه ای ندارد ، اما همه نوع بر اساس ورودی تکمیل می شوند.
تعاریف نوع نیز غواصی در استنتاج نوع ، حفظ آن بسیار پیچیده و دشوار به نظر می رسد. با این حال ، من با سخنان او بسیار همدلی کردم که این چیزها مسئولیت کتابخانه است ، نه مسئولیت کاربر.
نتیجه نهایی استنباط نوع به شرح زیر است. روشهای بومی در این پل اعلام شده است و انواع مربوطه از طریق نوعف صادر می شوند. سپس ، هنگامی که این نوع به عنوان عمومی در Linkbridge قرار داده می شود ، همه نوع بر اساس این در این پل تکمیل می شوند.
بنابراین ، این پل می تواند روشهای موجود مانند OpenInappBrowser را استنباط کند ، و می بینید که روش های موجود توصیه می شود.
اگر این مورد را کمی بیشتر اعمال کنیم ، ادغام با React Navigation نیز امکان پذیر است. همانطور که در تصویر زیر نشان داده شده است ، تمام صفحه های قابل پیمایش در stackrootparams React Native تعریف شده اند. هنگام استفاده از پیمایش پل در وب ، همه نام ها و پارامترهای تعریف شده قبلاً تعریف شده است.
به عبارت دیگر ، لیست صفحه نمایش تعریف شده در React Native می تواند بدون تعاریف نوع اضافی در وب استفاده شود. این تجربه تا حد زیادی تجربه توسعه دهنده را بهبود می بخشد و می تواند موقعیت هایی را که توسعه دهندگان از آن استفاده می کنند ، از بین ببرد. این منجر به تأثیر کاهش اشتباهات در صفحه نمایش برای حرکت در وب می شود.
هماهنگ سازی بین بومی و وب React
دریافت اطلاعات احراز هویت از برنامه بومی در WebView
با اجرای استنتاج نوع به خوبی در کتابخانه ، نسخه اول را مستقر کردم. فکر کردم همه چیز عالی خواهد بود ، اما با مشکل دیگری روبرو شدم. معلوم شد که این یک مسئله همگام سازی حالت مربوط به نشانه های احراز هویت است.
یکی از دلایلی که ارتباط بین وب و برنامه ضروری است انتقال و استفاده از اطلاعات تأیید اعتبار است. در ساختار فعلی ، ما ابتدا GetToken را در این پل اعلام می کنیم تا نشانه ها را برگردانیم و در وب می توانیم با این GetToken مقادیر را استخراج و استفاده کنیم.
با این حال ، چه اتفاقی می افتد اگر این نشانه در برنامه بومی منقضی شود و نشانه تغییر کند؟ React Native آخرین نشانه را خواهد داشت ، اما وب می تواند یک نشانه منقضی شده و وضعیت بدی ایجاد کند.
جدا کردن منطق اصلی وب برای ادغام: حالت مشترک
برای حل این وضعیت ، من فکر کردم هماهنگ سازی حالت بین React Native و Web ضروری است. مفهومی که من بر اساس این تفکر ایجاد کردم وضعیت مشترک است.
از آنجا که این مفهوم حول مدیریت دولت می چرخد ، باید با چارچوب های مدرن به راحتی یکپارچه شود. بنابراین ، من با جدا کردن از هسته وب شروع کردم و شروع به ساخت کتابخانه های مرتبط با دولت از منطق هسته وب کردم.
دولت مشترک همچنین با رویکرد استفاده محور طراحی شده است. این پل در ابتدا در شرایطی بود که فقط روش های بومی اعلام می شود. بنابراین ، این فقط می تواند توابع وعده را دریافت کند ، اما برای ذخیره مقادیر مانند نشانه ها ، من امکان ورود انواع ابتدایی مانند NULL یا رشته ها را فراهم کردم.
با نگاهی به قسمت اعلامیه بومی React در تصویر بالا ، Get و Set در معرض دید قرار می گیرند ، بنابراین می توان وضعیت فعلی و مقادیر را نیز تنظیم کرد که بسیار شبیه Zustand است. از آنجا که این کتابخانه ای است که دولت را مدیریت می کند ، من آن را با الهام بسیار از زوستند توسعه دادم.
در وب ، علاوه بر افشای روشهای موجود در React Native ، فروشگاه نیز در معرض این پل قرار دارد. این فروشگاه از اشتراک ها پشتیبانی می کند و به وب اجازه می دهد تا نسبت به تغییرات حالت از React Native واکنش نشان دهد. من آن را پیاده سازی کردم تا همگام سازی در وب از این طریق امکان پذیر باشد.
ادغام با React
مثال قبلی در وانیل جاوا اسکریپت است. با تشکر از این ، ادغام با React به راحتی امکان پذیر است. React 18 قلاب AssiNCEXTERNALSTORE را معرفی کرد ، که ادغام یکپارچه فروشگاه های خارجی را در جریان رندر React امکان پذیر می کند. من توانستم این کار را به یک کتابخانه حالت React به نام WebView-Bridge/React با بسته بندی این قلاب گسترش دهم.
اگر فروشگاه را در UseBridge قرار دهید ، می توانید از STATE نشانه هایی دریافت کرده و از آن استفاده کنید. این نشانه در وب وجود دارد اما در زمان واقعی با حالت React Native هماهنگ می ماند.
استفاده نهایی: حالت مشترک
حالا بیایید به استفاده نهایی بپردازیم. در React Native در زیر ، تعداد به عنوان 0 اعلام می شود و با افزایش 1 افزایش می یابد. از آنجا که React Native نیز واکنش نشان می دهد ، اگر AppBridge را در UseBridge قرار دهید ، می توانید از حالت به نام COUNT و روشی که به نام افزایش می یابد استفاده کنید.
در وب ، این پل از طریق Linkbridge و AppBridge اعلام می شود و از طریق فروشگاه این پل و Usebridge می توانید از منطق هسته بومی ، تعداد و استفاده را استخراج و افزایش دهید. این به وب اجازه می دهد تا حالت مشترک را در زمان واقعی مصرف و به روز کنید ، کاملاً با React Native هماهنگ شود.
استفاده نهایی: روش بومی
همچنین ، همانطور که در تصویر زیر نشان داده شده است ، این پل ورودی را به سلام و احوالپرسی می کند و مقدار برگشتی به نام MSG را برمی گرداند. از آنجا که این پل از ژنرال ها برای اجرای ایمنی نوع استفاده می کند ، فراخوانی روشهای نامشخص بلافاصله خطاهای نوع را حتی در صورت فراخوانی در خارج از کشور افزایش می دهد. همچنین ، هنگامی که ورودی اشتباه است ، خطاهای نوع رخ می دهد ، و هنگامی که ورودی به طور عادی دریافت می شود ، می بینید که انواع مقادیر پاسخ به درستی نمایش داده می شوند.
نتیجه گیری: درسهایی که از ایجاد کتابخانه آموخته شده است
سرانجام ، من با موفقیت در تهیه یک کتابخانه ارتباطی WebView از نوع ، کاهش تعاریف نوع دستی و استفاده از استنتاج را تا حد امکان به پایان رساندم تا همه نوع بر اساس ورودی تکمیل شوند. ساخت این کتابخانه بینش و درسهایی ارزشمند را در بین طراحی و اجرای ارائه می دهد.
با اعتقاد به اینكه تجربه بزرگ توسعه دهنده از الگوهای استفاده ناشی می شود ، من قبل از اجرای ویژگی ها ، سناریوهای استفاده بصری را در اولویت قرار دادم. در نتیجه ، این رویکرد منجر به انتزاع تمیز و نتایج شد که به خوبی با نیازهای توسعه عملی مطابقت داشت. همچنین ، کتابخانه من بسیار شبیه TRPC و Zustand است. از طریق توسعه ، می توانم از کتابخانه های مختلفی استفاده کنم که خود یادگیری زیادی را ارائه می داد. علاوه بر این ، من می توانم تجربه ارزشمند استفاده مستقیم از مفاهیم آموخته شده را برای توسعه داشته باشم.
سرانجام ، از آنجا که من از ابتدا از منطق هسته وب شروع کردم ، ادغام با سایر چارچوب های مدرن React به راحتی امکان پذیر بود. اگر من کتابخانه دولتی را با استفاده از Vue.js بنا کردم ، ادغام چارچوب متقابل به طور قابل توجهی دشوارتر بود.
از این طریق ، من همچنین می توانم یاد بگیرم که معماری مقیاس پذیر چیست.
کتابخانه معرفی شده امروز منبع باز است و با نام WebView-Bridge منتشر می شود.
این شامل بسیاری از ویژگی های اضافی در این مقاله نیست. بنابراین اگر علاقه مند هستید ، برای کسب اطلاعات بیشتر و بررسی اسناد مرتبط ، توصیه می کنم از آدرس زیر بازدید کنید. اگر آن را دوست دارید ، لطفاً به آن ستاره ای در GitHub بدهید. ممنون
