وب کامپوننت ها مجموعه‌ای بومی از ویژگی‌ها هستند که محدوده بندی فوق العاده‌ای از سبک‌ها و عملکردها را فراهم می‌کنند. آنها می‌توانند در یک صفحه وب خاص با هر فریمورک جاوااسکریپت (به عنوان مثال React ، Vue ، Angular ، Svelte و موارد دیگر) به انتخاب شما استفاده شوند. این امر باعث می‌شود وب کامپوننت ها برای ساخت عناصر قابل استفاده مجدد که باید به صورت عمومی به اشتراک گذاشته شوند یا در چندین پروژه مورد استفاده مجدد قرار گیرند، مناسب باشند.
در حقیقت مشکلاتی هم وجود دارد که می‌تواند وب کامپوننت ها را در برخی از پروژه‌ها تقریبا غیر قابل استفاده کند.
در این مقاله توضیح می‌دهیم که چه چیزی باعث عملکرد فوق العاده وب کامپوننت ها می‌شود و اینکه چه اشکالاتی دارند. این راهنما به شما کمک می‌کند تصمیم بگیرید که آیا باید از آنها در پروژه‌های خود استفاده کنید یا خیر.
ویژگی‌های خوب
دو ویژگی اصلی که وب کامپوننت ها را قدرتمند می‌کند Custom Elements API و Shadow DOM است.
Custom Elements API چیزی است که به شما امکان می‌دهد کامپوننت های خود را به عنوان عناصر جدید HTML ایجاد و ثبت کنید. همچنین به شما این امکان را می‌دهد که برای عنصر جدید خود فراخوانی چرخه عمر را تعریف کنید. به طور کلی درک و ورود به آن بسیار عالی و نسبتا ساده است، هم برای توسعه دهندگان تازه کار و هم برای توسعه دهندگان باتجربه.
Shadow DOM چیزی است که کپسوله سازی استایل‌ها را فراهم می‌کند. این به کامپوننت های شما DOM خاص خود را می‌دهد که جدا از بقیه داکیومنت شما است. این بدان معنی است که استایل‌های گلوبال نمی‌توانند بر آن تأثیر بگذارند (به جز خصوصیات / متغیرهای سفارشی CSS) و استایل‌های خاص آن نمی‌توانند بر سایر عناصر موجود در داکیومنت اصلی تأثیر بگذارند.
عناصر <template> و <slot> نیز در بیشتر عناصر سفارشی استفاده می‌شوند که به شما امکان می دهند به راحتی الگوهایی با محتوای پویا ایجاد کنید بدون اینکه بخواهید به سیستم یا زبان قالب شخص ثالثی نیاز پیدا کنید.
پشتیبانی از مرورگر برای همه این ویژگی‌ها بسیار خوب است، مگر اینکه هنوز از اینترنت اکسپلورر استفاده کنید! که البته بعید به نظر می‌رسد توسعه دهنده‌ای این کار را کند. یک استثنا در این مورد وجود دارد که بعدا در بخش "بد" توضیح داده خواهد شد.
همانطور که در ابتدای مقاله ذکر شد، نه تنها وب کامپوننت ها با تقریبا هر فریمورک جاوااسکریپت موجود سازگار هستند، بلکه می‌توانند در جاوااسکریپت وانیلا هم استفاده شوند. به این دلیل که وب کامپوننت ها در واقع فقط کلاس‌های ES6 هستند که HTMLElement بومی را گسترش می‌دهند. این بدان معناست که شما می‌توانید کامپوننت های سازنده را در کل پروژه یا کل اکوسیستم شرکت خود به اشتراک بگذارید.
علاوه بر این چندین کتابخانه و پکیج عالی برای سهولت در ایجاد وب کامپوننت ها و همچنین یک بستر آنلاین وجود دارد که می‌توانید آنها را با دیگران به اشتراک بگذارید: webcomponents.org
ویژگی‌های بد
فلش زدن محتوای بدون استایل
بیایید با Custom Elements API شروع کنیم. تنها نقصی که در مورد عناصر سفارشی تجربه کرده‌ام، احتمال وجود فلش در محتوای بدون استایل است. از آنجا که عناصر سفارشی در جاوااسکریپت تعریف و ثبت می‌گردند، ممکن است چند میلی ثانیه طول بکشد تا بارگیری، پردازش، ثبت و سرانجام رندر شوند. همزمان با اینکه این اتفاق می‌افتد، عناصر سفارشی شما لحظه‌ای بدون استایل یا پنهان می‌شوند.
این می‌تواند یک عیب اساسی برای یک وبسایت پربازدید باشد که در آن شما فقط چند ثانیه فرصت دارید تا در بازدید اول توجه مخاطب را جلب کنید. اما در برنامه‌های وب این یک مشکل بحرانی نیست، چراکه حافظه کش مرورگر شما به طور قابل توجهی این مسئله را در بارگیری اولیه تنظیم می‌کند.
در اینجا مثالی از FOUC با یک وب کامپوننت " tabbed container" در بارگیری مجدد بدون حافظه کش (در یک سرور توسعه محلی) آورده شده است:
در زیر همان کامپوننت رندر شده را هنگام بارگیری مجدد با حافظه کش مرورگر (باز هم در یک سرور توسعه محلی) می‌بینید:
همانطور که مشاهده می‌کنید، حافظه کش مرورگر این مشکل را برای بازدیدهای مکرر برطرف کرده و آن را نشان نمی‌دهد.
Shadow DOM به خوبی با فرم‌های بومی سازگار نیست
بزرگترین مسئله‌ای که در وب کامپوننت ها با آن مواجه شده‌ام این واقعیت است که آنها با ویژگی‌های یک فرم بومی به خوبی کنار نمی‌آیند. این به دو چیز برمی‌گردد:
- عناصر سفارشی نمی‌توانند عناصر دیگری به غیر از HTMLElement را گسترش دهند (بدون راه حل‌های خسته کننده و اشکالات عمده).
- عناصر فرم داخل Shadow DOM توسط فرم اصلی کامپوننت در نظر گرفته نمی‌شوند.
به یاد دارید که Shadow DOM چگونه از استایل‌های گلوبال استفاده نمی‌کرد؟ این بدان معناست که اگر می‌خواهید از یک <form> در داخل یک وب کامپوننت استفاده کنید، باید استایل‌های <input>، <select>، <textarea>، <button>، <label>، <fieldset> و موارد دیگر را دوباره تعریف کنید.
مطمئنا می‌توانید هر یک از این عناصر را جزیی از وب کامپوننت خاص خود قرار دهید، بنابراین هر یک استایل خاص خود را دارند. با این حال از آنجا که عناصر فرم مانند HTMLInputElement توسط عناصر سفارشی قابل گسترش نیستند، کامپوننت ورودی سفارشی شما باید <input> را در Shadow DOM خود وارد کند. این همان چیزی است که شما را با مشکل بعدی روبه رو می‌کند: ورودی‌ها (و سایر عناصر فرم) در Shadow DOM بخشی از فرم محسوب نمی‌شوند.
به عنوان مثال اگر دکمه ارسال فرم درون Shadow DOM باشد، با فشار دادن Enter در ورودی دیگر نمی‌توان فرم را ارسال کرد، مگر اینکه شنونده رویداد keydown خود را اضافه کنید تا این ویژگی را خودتان تعریف کنید.
در اینجا مثالی دیگر آورده شده که کمی پیچیده‌تر و گویاتر است. اگر می‌خواهید ورودی سفارشی ایجاد کنید، سه راه حل دارید:
- می‌توانید یک <input type="hidden"> در DOM معمولی در کنار عنصر سفارشی خود ایجاد کنید و یک دسته از ویژگی‌های داخلی را به صورت دستی تکرار کنید تا اطمینان حاصل کنید که ورودی شما همیشه به درستی همگام سازی می‌شود. این باعث ایجاد رویدادهای مناسب می‌گردد، به درستی تأیید می‌شود و به خوبی قابل دسترس است، خوب به نظر می‌رسد و عالی کار می‌کند.
- می‌توانید هر عنصر فرم را از جمله خود <form> ایجاد کرده و از عناصر بومی <form> برای کل پروژه صرف نظر کنید.
- هر فرم را که از این عنصر ورودی سفارشی استفاده می‌کند با نوشتن کد جاوااسکریپت مدیریت کنید.
اگر قبلا با جاوااسکریپت کار کرده‌اید، می‌توانید تک تک فرم‌ها را مدیریت کنید.
با این حال اگر شما بیشتر به وانیلا گرایش دارید، در زمینه توسعه وب جدیدتر هستید یا به سادگی راه حل‌ها و محیط‌های ساده را می‌پسندید، این یک معامله اصلی بزرگ محسوب می‌شود.
درصدی غیر قابل چشم پوشی از وب کامپوننت ها که می‌خواهم ایجاد کنیم، کار با فرم‌ها یا عناصر فرم به یک روش استاندارد یا روشی دیگر است و من انتظار دارم که برای اکثر توسعه دهندگان دیگر نیز همین گونه باشد.
ویژگی‌های زشت
بدترین قسمت این است که در وب اطلاعات زیادی در مورد آنچه برای رفع یا دور زدن این مسئله ناسازگاری با اشکال بومی انجام می‌شود، وجود ندارد.
کتابخانه‌های وب کامپوننت ها مانند Shoelace به سادگی عنصر فرم سفارشی خود را پیاده سازی می‌کنند که باید به صورت دستی در جاوااسکریپت مدیریت شود.
کتابخانه‌هایی که هدف آنها کمک به ساخت وب کامپوننت هاست مانند Lit گوگل امکان گسترش عناصر داخلی را ندارند؛ زیرا مرورگر سافاری از شخصی سازی عناصر داخلی پشتیبانی نمی‌کند.
به طور کلی بعد از گذشت چند ماه شروع کار با وب کامپوننت ها خودم را بدبین نمی‌دانم، اما از وضعیت فعلی و آینده آنها خارج از پروژه‌های جاوااسکریپت و این اکوسیستم کمی ناامید شده‌ام.
من هنوز معتقدم ایده و اجرای کلی وب کامپوننت ها عالی است. اما ایراداتی که به ویژگی‌های بومی وارد می‌شود، یادگیری و پیاده سازی آنها را کمی دچار مشکل می‌کند.
شما باید از وب کامپوننت ها استفاده کنید اگر:
- قبلا همه فرم‌های خود را به صورت دستی در جاوااسکریپت مدیریت می‌کردید.
- چندین پروژه یا اکوسیستم با پشته‌های مختلف فناوری دارید که در آنها نیاز به اشتراک یا استفاده مجدد از کامپوننت ها می‌باشد (یا قصد داشتن آنها را دارید).
- مهم نیست که قبل از شروع کار روی ویژگی‌های مربوط به مشاغل شخصی خود زمان زیادی را برای اجرای مجدد قابلیت‌های داخلی و قابلیت دسترسی اختصاص دهید (یا اگر می‌توانید از کتابخانه کامپوننت های موجود مانند Shoelace برای صرفه جویی در توسعه اولیه استفاده کنید).
- به کامپوننت های خود برای تعامل با فرم‌ها یا عناصر فرم نیازی ندارید.
شما نباید از وب کامپوننت ها استفاده کنید اگر:
- می‌خواهید توانایی استفاده از فرم‌های بومی را حفظ کنید.
- به پشتیبانی مرورگرهای قدیمی نیاز دارید.
کلام آخر
اگر تا به حال با جاوااسکریپت یا فریمورک‌های آن کار نکرده‌اید اما همچنان می‌خواهید از وب کامپوننت ها برای فرم‌های خود استفاده کنید (به عنوان مثال در حال ساخت برنامه وب با لاراول یا سیمفونی هستید)، همیشه امکان توسعه یک فرم گلوبال برای غلبه بر مشکلاتی که در این مقاله شرح‌داده شده‌اند، وجود دارد.
مطمئنا این کار پیچیده‌تر از استفاده از فرم‌های بومی است و شما را ملزم می‌کند قبل از شروع کار، تلاش و تست بیشتری انجام دهید اما احتمالا ساده ترین راه حل است.
اگر راه حل یا روش دیگری در ذهن دارید، می‌توانید در بخش نظرات آن را به اشتراک بگذارید.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید