React Native یک فریمورک عالی برای توسعه اپلیکیشنهای موبایل چند پلتفرمی برای گوشیهای مبتنی بر iOS و اندروید است. در این مقاله قصد داریم با همدیگر فرایند ساخت یک اپلیکیشن «کوچک» آب و هوا را با استفاده از React Native و Expo از طریق واکشی دادهها به صورت آنی مرور کنیم. اگر تاکنون هرگز با React Native کار نکردهاید، میتوانید از این راهنمای گام به گام به عنوان آغاز مسیر خود برای تبدیل شدن به یک توسعهدهنده اپلیکیشنهای موبایل استفاده و یک پروژه جالب به رزومه خود اضافه کنید.
اگر تجربه کار با React.js را داشته باشید، در یادگیری این راهنما هیچ مشکلی نخواهید داشت. اگر در زمینه جاوا اسکریپت یا اکوسیستم React.js یک تازهکار محسوب میشوید، پیشنهاد میکنیم پیش از ادامه مطالعه این مقاله، برای این که بتوانید مفاهیم مقدماتی این راهنما را درک کنید، سری به این آموزشها نیز بزنید:
توجه داشته باشید که React Native یک فریمورک اپلیکیشن موبایل هیبرید نیست. این فریمورک از پلی بین جاوا اسکریپت و API-های native پلتفرم مقصد استفاده میکند. برای کسب اطلاعات بیشتر در این زمینه پیشنهاد میکنیم سری به مستندات رسمی (+) React Native بزنید.
ما در این راهنما از Expo (+) استفاده خواهیم کرد که به عنوان «سریعترین روش برای ساخت اپلیکیشن» توصیف شده است. Expo یک مجموعه اوپنسورس از ابزارها و سرویسهایی است که به طور خاص زمانی که تازه وارد دنیای React Native شدهاید، بسیار به کار شما میآید. ابزار توسعهای که در این نوشته برای Expo استفاده میکنیم، Expo XDE (+) نام دارد.
همه موارد مورد نیاز اینها هستند. بنابراین در ادامه فرایند توسعه اپلیکیشن خود را آغاز میکنیم.
Expo XDE را پس از نصب کردن باز کنید و روی Create New Project کلیک کنید:

نام اپلیکیشن خود را وارد کرده و روی Create کلیک کنید. نام اپلیکیشن باید با حروف کوچک لاتین باشد. دلیل این مسئله آن است که رابط کاربری Expo XDE از کاراکترهای حروف بزرگ پشتیبانی نمیکند.


Expo در پسزمینه از ابزار مدیریت پکیج React Native برای شبیهسازی اپلیکیشن و بارگذاری وابستگیها از فایل package.json اپلیکیشن استفاده میکند. مزیت استفاده از Expo EDE این است که لازم نیست پنجرههای ترمینال چندگانه را باز کنید و میتوانید اپلیکیشن را همزمان با توسعه روی دستگاه واقعی تست کنید. زمانی که این مرحله پایان یافت، کد منبع اپلیکیشن ایجاد میشود و میتوانیم آن را در یک شبیهساز روی سیستم محلی آغاز کنیم تا پیشنمایشی از اپلیکیشن پیشفرض به دست بیاوریم.

اگر از Mac استفاده میکنید، باید مطمئن شوید که Xcode روی سیستمتان نصب شده است. اگر از ویندوز استفاده میکنید، دستورالعملهای نصب اندروید استودیو برای اجرای شبیهساز را پیگیری کنید.
اگر میخواهید از مرحله شبیهسازی اپلیکیشن عبور کنید و آن را بدون ایجاد هر گونه فایل apk. یا ipa. روی دستگاه واقعی تست کنید، میتوانید کلاینت Expo را نصب کرده و کد QR ایجاد شده از سوی Expo XDE را اسکن کنید.

زمانی که کد منبع کار بستهبندی را انجام داد، یک پیام موفقیت در ترمینال Expo XDE نمایش مییابد:

در این زمان میتوانید ببینید که اپلیکیشن پیشفرض روی دستگاه مربوطه اجرا شده است:

پیام نمایش یافته در این صفحه کد سادهای است که از سوی App.js در ریشه اپلیکیشن ما رندر شده است:
<Text> را به صورت زیر تغییر دهید:
در این مرحله مشاهده میکنید که خروجی رندر میشود و اپلیکیشن به صورت خودکار و آنی بارگذاری مجدد میشود. برای مشاهده تغییرات نیازی به رفرش کردن وجود دارد.

بدین ترتیب مرحله نخست آغاز کار را انجام دادهایم. در مرحله بعدی یک پروتوتایپ استاتیک از اپلیکیشن خود میسازیم تا ببینیم چه سر و شکلی خواهد داشت.
در این مرحله نخستین صفحه اپلیکیشن خود را توسعه میدهیم که یک صفحه بارگذاری است. بدین منظور در فایل App.js یک «حالت محلی» (local state) تعریف کنید:
کد فوق اعلام میکند که وقتی حالت محلی شیء isLoading نادرست است، نام اپلیکیشن را باید نشان دهیم. این همان چیزی است که قصد داریم رندر کنیم. در ادامه و زمانی که دادهها را با موفقیت واکشی کردیم، به جای نمایش دادن نام اپلیکیشن، وضعیت آب و هوا را در این صفحه نمایش خواهیم داد. در حال حاضر، این پیام را بررسی میکنیم و بدین منظور نخست باید به این سؤال پاسخ دهیم که اگر اپلیکیشن ما در حالت بارگذاری باشد چه خواهد شد؟ متن پیام را به این صفحه اضافه میکنیم تا به کاربر نشان دهیم اپلیکیشن در حال واکشی کردن دادهها است.
هنگامی که اپلیکیشن ما کار بارگذاری دادهها از API را به پایان ببرد، حالت isLoading را به صورت False تنظیم میکنیم:

ما یک کامپوننت «آب و هوا» (Weather) در مسیر components/Weather.js./ تعریف میکنیم. کد قالب برای هر صفحه شرایط جوی، یکسان خواهد بود و به دو view تقسیم میشود که یکی هدر و دیگری بدنه است. ویوی هدر آیکون شرایط جوی و دما را نشان میدهد و ویوی بدنه متن مرتبط با شرایط جوی را نمایش خواهد داد.
در Weather.js، شروع به تعریف کردن دو کانتینر درون کانتینر اصلی میکنیم که یکی headerContainer و دیگری bodyContainer است. توجه داشته باشید که کامپوننت weather به صورت یک کلاس و نه یک تابع تعریف میشود تا props را دریافت کند و از این رو میتواند یک حالت را مدیریت کند.
ما از MaterialCommunityIcons استفاده خواهیم کرد که به همراه Expo به عنوان یک کتابخانه فرعی از کتابخانه humongous به نام vector-icons عرضه میشود:
بدین ترتیب اپلیکیشن ما پس از اتمام مرحله پروتوتایپ به صورت زیر در خواهد آمد:

برای واکشی دادهها به صورت آنی از API نقشه Open Weather (+) استفاده میکنیم، چون کاملاً مفید و سازگار است. برای ارتباط با این API باید یک کلید API داشته باشیم، یعنی باید یک حساب کاربری در سایت ایجاد کنیم تا کلید API را دریافت کنیم. توجه داشته باشید که فعال شدن کلید API مربوط به Open Weather دستکم 10 دقیقه طول میکشد.
در وبسایت به بخش API section بروید. چنان که میبینید نیازهای ما بر اساس دادههای جوی حاضر تأمین میشود. ما قصد داریم کلید API را در فایل utils/WeatherAPIKey.js/. ذخیره کنیم.
طرز کار API مربوط به Open Weather چنین است که باید مختصات طول و عرض جغرافیایی را از روی مکان دستگاه به آن ارائه کنیم. سپس دادهها را از سرور آن به صورت یک شیء JSON واکشی میکنیم. زمان کار با سرور به دو چیز نیاز داریم که یکی دما و دیگری شرایط جوی است. ما باید این دو مقدار را در حالت محلی App.js ذخیره کنیم.
در این مرحله کار خود را ایمپورت کردن کلید API که قبلاً تعریف کردیم آغاز میکنیم و سپس حالت خود را با مقادیر temperature ،weatherCondition و error بهروزرسانی میکنیم. بدین منظور از ()componentDidMount استفاده میکنیم که یک متد چرخه عمر است که به رندر مجدد اپلیکیشن پس از واکشی دادهها از سوی API کمک میکند. این متد همچنین در زمینه بهروزرسانی حالت به ما کمک خواهد کرد. ما از یک API به نام navigator نیز برای دریافت موقعیت دستگاه استفاده میکنیم. این همان جایی است که API جاوا اسکریپت از طریق یک پل با API نیتیو همکاری میکند. ما مقادیر طول و عرض جغرافیایی را به تابع سفارشی خود با نام fetchWeather ارسال میکنیم که API مربوط به Open Weather Map در آن فراخوانی میشود.
نتیجه کار در قالب JSON است و اگر آن را در کنسول لاگ کنید، میتوانید نتیجه را به صورت یک شیء JSON در ترمینال Expo مشاهده کنید که مقادیر زیادی در خود دارد. ما تنها به مقدار دما و شرایط جوی نیاز داریم و سپس حالت محلی خود را با مقادیر جدیدی که به دست آوردهایم بهروزرسانی میکنیم. units=metric& در انتهای فراخوانی API موجب میشود که دما از مقیاس کلوین به سلسیوس تبدیل شود.
اینک تنها کاری که باید انجام دهیم، ارسال این دو مقدار حالت محلی به صورت props به کامپوننت weather است و سپس آن را طوری بهروزرسانی میکنیم که آن prop-ها را دریافت کند. ابتدا در فایل App.js تغییرات زیر را ایجاد کنید:
فایل weather.js را نیز به صورت زیر بهروزرسانی کنید:

از آنجا که بخش دشوار کار که واکشی دادهها به صورت همزمان بود را انجام دادیم، اینک باید کاری کنیم که کامپوننت weather ما بر اساس مقادیری که دریافت میکند رفتاری دینامیک داشته باشد. این رفتار دینامیک با withweatherCondition مرتبط خواهد بود.
با استفاده از withweatherCondition میتوانیم تغییراتی را در پسزمینه، عنوان، عنوان فرعی آیکون جوی خود تعریف کنیم. کار خود را با تعریف از پیش آماده شرایط جوی در یک فایل به نام utils/WeatherConditions.js./ آغاز میکنیم:
این شرایط جوی به وسیله API مربوط به Open Weather ارائه میشوند. سپس این فایل را در weather.js ایمپورت میکنیم. همچنین PropTypes را برای دو prop که از App.js دریافت میکنیم تعریف خواهیم کرد. به کد زیر توجه کنید:
بخش غالب کد منبع یکسان است. ما اینک برخی موارد را از طریق دسترسی به prop-های شرایط جوی به صورت دینامیک تغییر میدهیم که شامل پسزمینه، آیکون، نام شرایط جوی و عنوان فرعی آن میشود. همچنین میتوانید تغییراتی بنا به دلخواه خود در استایل اپلیکیشن ایجاد کنید تا ظاهری مینیمالتر یا زیباتر بیابد.

نکته: پیش از آن که اپلیکیشن را روی دستگاه واقعی خود اجرا کنید، باید مطمئن شوید که دسترسی اینترنت و مکان روی دستگاه برای این اپلیکیشن فعال شده است. ما در این مقاله در مورد دسترسیهای اپلیکیشن صحبت نکردیم، چون تا حدودی خارج از حیطه این مطلب به حساب میآید. برای مشاهده کد کامل این پروژه میتوانید به این ریپوی گیتهاب (+) مراجعه کنید.
اگر این نوشته برای شما مفید بوده است، آموزشهای زیر نیز به شما پیشنهاد میشوند:
در این مقاله در مورد مفهوم تصاویر واکنش گرا یا Responsive صحبت خواهیم کرد. تصاویر واکنشگرا به تصاویری گفته میشود که روی دستگاههای مختلف که اندازههای صفحه، وضوح تصویر و دیگر ویژگیهای متفاوت دارند، به طرز مناسبی نمایش پیدا میکنند. همچنین با امکانات HTML برای پیادهسازی تصاویر واکنشگرا آشنا خواهیم شد. تصاویر واکنشگرا بخشی از طراحی وب واکنشگرا هستند. شما برای مطالعه این مطلب باید با مبانی HTML و شیوه افزودن تصاویر استاتیک به یک صفحه وب آشنا باشید. هدف از این نوشته، آشنایی با شیوه استفاده از ویژگیهایی مانند srcset برای عنصر <picture> جهت پیادهسازی راهحلهای تصویر واکنشگرا در یک وبسایت است.
برای مطالعه قسمت قبلی این مجموعه مطلب میتوانید روی لینک زیر کلیک کنید:
سناریوی متداول زیر را تصور کنید. یک وبسایت معمولی میتواند شامل یک تصویر هدر و برخی تصاویر محتوایی در زیر هدر باشد. تصویر هدر به طور معمول کل عرض صفحه را پوشش میدهد و تصویر محتوا یک بخش (یا همه) عرض ستون محتوا را اشغال میکند. به تصویر زیر توجه کنید:

این وضعیت روی یک دستگاه با صفحه عریض مانند لپتاپ یا دسکتاپ به خوبی نمایش پیدا میکند. کد صفحه فوق به صورت زیر است:
ما در این بخش قصد نداریم کدهای CSS را مورد بررسی دقیقی قرار دهیم و صرفاً برخی موارد را در ادامه فهرستبندی کردهایم:
با این وجود، زمانی که این صفحه وب را روی دستگاههایی با عرض کمتر مشاهده میکنید با برخی مشکلات مواجه خواهید شد. در این موارد هدر ظاهر مناسبی دارد؛ اما در یک صفحه موبایل ارتفاع بیشتری از صفحه را اشغال میکند. در این اندازه، دیدن افراد درون نخستین تصویر محتوا دشوار میشود.

یکی از راههای برای بهبود این وضعیت آن است که نسخه برش یافتهای از تصویر را نمایش دهیم که وقتی سایت روی صفحههای کمعرض نمایش پیدا میکند، صرفاً جزییات مهم تصویر را نمایش دهد. تصویر دوم برش یافته نیز میتواند برای نمایش روی صفحه دستگاههایی با عرض متوسط مانند تبلت استفاده شود. این مشکل به طور معمول به نام مسئله «art direction» شناخته میشود.
به علاوه در صورتی که قرار است تصویرها روی یک صفحه کوچک موبایل نمایش یابند، نیازی به جاسازی چنین تصاویر بزرگی روی صفحه نیست. این وضعیت به نام مسئله «Resolution Switching» شناخته میشود. چنان که در بخش قبلی این سری مقالات در مورد گرافیکهای برداری (+) گفتیم، تصویر raster مجموعهای از پیکسلها است که عرض و ارتفاع مشخصی دارد. یک تصویر کوچک raster در صورت نمایش در اندازهای بزرگتر از اندازه اصلی خودش تار به نظر میرسد (اما گرافیک برداری چنین نیست).
به طور عکس، نمایش یک تصویر بزرگ روی صفحهای که بسیار کوچکتر از اندازه تصویر است، کار بیهودهای محسوب میشود. این کار موجب هدر رفتن پهنای باند میشود و به طور خاص برای آن دسته از کاربران موبایل حائز اهمیت است که نمیخواهند تصویر بزرگی را که برای نمایشگرهای دسکتاپ طراحی شده، دانلود کنند. یک راهحل ایدهآل در این موارد، آن است که چند وضوح تصویر مختلف داشته باشیم و بسته به دستگاههایی که به دادههای روی وبسایت دسترسی مییابند، نسخه مناسب را ارائه کنیم.
برای این که متوجه بشوید مسائل پیچیدهتر از این هستند، باید بگوییم که برخی دستگاهها صفحههای با وضوح تصویر بالاتر دارند که به تصاویر بزرگتر از مقدار معمول نیاز دارند تا به خوبی نمایش پیدا کنند. این مشکل نیز شبیه به مشکل فوق است؛ اما در چارچوب متفاوتی قرار دارد.
ممکن است فکر کنید که تصاویر برداری میتوانند این مشکلات را حل کنند و البته تا حدی نیز قادر به حل این مسائل هستند. آنها هم اندازه کوچکی دارند و هم به خوبی تغییر مقیاس پیدا میکنند و در هر جایی که ممکن است بهتر است از آنها استفاده کنید. با این که این تصاویر برای برخی از انواع تصاویر مانند الگوها، عناصر اینترفیس و غیره مناسب هستند؛ اما برای برخی از انواع دیگر تصویر مانند عکسها که نیاز به جزییات زیادی دارند به سرعت حجیم میشوند. قالب تصاویر raster مانند JPEG برای این نوع از تصاویر که در مثال فوق نیز مشاهده کردید، مناسبتر هستند.
در اوایل تا اواسط دهه 90 میلادی، زمانی که وب تازه متولد شده بود، این نوع از مشکلات چندان رایج نبودند، چون دستگاههایی که امکان مرور وب را داشتند، لپتاپها و رایانههای دسکتاپ بودند و از این رو مهندسانِ مرورگرها و طراحان به پیادهسازی چنین راهحلهایی حتی فکر هم نمیکردند. فناوری تصاویر واکنشگرا در سالهای اخیر و برای حل مشکلاتی که در بخشهای قبلی اشاره کردیم ابداع شده است و امکان ارائه چندین تصویر از سوی مرورگر را فراهم ساخته است. این تصاویر همگی موضوع واحدی را نمایش دهند؛ اما تعداد پیکسلهای متفاوتی دارند (Resolution Switching) و یا این که تصاویر مختلف که مناسب فضابندیهای متفاوت هستند ارائه میکنند (art direction).
نکته: دقت کنید که ویژگیهای جدیدی که در این نوشته بررسی میکنیم، یعنی srcset ،sizes و <picture> هنوز از سوی همه نسخههای مرورگرهای مدرن موبایل و دسکتاپ پشتیبانی نمیشوند.
در این بخش روی دو مسئلهای متمرکز میشویم که در بخش قبلی تشریح کردیم و روش حل آنها را با استفاده از ویژگیهای تصاویر واکنشگرا در HTML مورد بررسی قرار میدهیم. باید توجه داشته باشید که ما در این بخش روی <img>-های HTML تمرکز خواهیم کرد. این عناصر را در ناحیه محتوای مثال ابتدای این نوشته مشاهده کردید و دیدید که تصویر موجود در هدر سایت صرفاً برای تزیین است و لذا توسط تصاویر پسزمینه CSS پیادهسازی شده است. میتوان استدلال کرد که CSS نسبت به HTML ابزارهای بهتری برای طراحی واکنشگرا ارائه کرده است.
ابتدا باید از خود بپرسیم resolution switching قرار است کدام مشکل را حل کند؟ ما میخواهیم محتوای تصویری یکسانی و البته با اندازه بزرگتر یا کوچکتر، بسته به اندازه صفحه دستگاه مقصد نمایش دهیم. این همان موقعیتی است که باید از محتوای تصویر دوم که در مثال فوق معرفی کردیم، استفاده کنیم. عنصر استاندارد <img> به طور سنتی تنها امکان تعیین یک فایل منبع منفرد برای تصویر در مرورگر ارائه میکند:
با این وجود میتوانیم از دو خصوصیت جدید srcset و sizes استفاده کنیم تا چند تصویر منبع اضافی همراه با سرنخهایی در اختیار مرورگر قرار دهیم تا نوع مناسب را بسته به موقعیت انتخاب کند. در ادامه یک نمونه استفاده از این ویژگیها را مشاهده میکنید:
خصوصیتهای srcset و sizes به ظاهر پیچیده به نظر میرسند؛ اما اگر آنها را به صورت فوق قالببندی کنید و هر خصوصیت را در یک خط جدید قرار دهید، درک آنها چندان دشوار نخواهد بود. هر مقدار شامل یک لیست است که با ویرگول از هم جدا میشود و هر بخش از لیست از سه بخش فرعی تشکیل یافته است. محتوای هر ردیف به صورت زیر است:
srcset مجموع تصاویری که مرورگر میتواند از بین آنها انتخاب کند را شامل میشود و اندازه هر تصویر را نیز نمایش میدهد. پیش از هر ویرگول موارد زیر را مینویسیم:
Sizes مجموعهای از «شرایط رسانه» (Media Condition) است؛ یعنی عرض صفحه را تعریف و تعیین میکند که هر کدام از شرطهای فوق تا چه اندازهای باید انتخاب شوند. اینها سرنخهایی هستند که قبلاً در موردش صحبت کردیم. در این حالت، پیش از هر ویرگول موارد زیر را مینویسیم:
نکته: در مورد عرض اسلات باید یک طول مطلق (px ،em) یا طول نسبی صفحه (vw) ارائه کنید؛ اما امکان تعیین درصد وجود ندارد. ممکن است متوجه شده باشید که آخرین عرض اسلات شرط رسانهای ندارد. دلیل این مسئله آن است که این مقدار پیشفرض است و هنگامی که هیچ شرط رسانهای صحیح نباشد انتخاب میشود. مرورگر هر چیزی را که پس از اولین شرط سازگار بیابد نادیده میگیرد، بنابراین در مورد ترتیببندی شرطهای رسانهای با احتیاط عمل کنید.
بدین ترتیب وقتی این خصوصیتها تنظیم شوند، مرورگر به صورت زیر عمل خواهد کرد:
این همه داستان است. بنابراین در این مرحله اگر یک مرورگر مناسب با اندازه صفحه 480 پیکسل وجود داشته باشد، شرط رسانهای (max-width: 480px) درست خواهد بود و از این رو اسلات 440px انتخاب میشود و بدین ترتیب تصویر elva-fairy-480w.jpg بارگذاری خواهد شد، زیرا عرض ذاتی آن 480w به 440px نزدیکترین مطابقت را دارد. تصویر 800px روی دیسک فضایی به اندازه 128 کیلوبایت اشغال میکند؛ در حالی که نسخه 480 پیکسلی تنها 63 کیلوبایت حجم دارد که موجب صرفهجویی 65 کیلوبایت پهنای باند در زمان بارگذاری میشود. اینک تصور کنید اگر این صفحهای باشد که تصاویر زیادی روی آن باشد، استفاده از این تکنیک موجب میشود که کاربران موبایل از پهنای باند زیادی استفاده کنند.
مرورگرهای قدیمیتر که از این ویژگیها پشتیبانی نمیکنند، آنها را نادیده میگیرند و به بارگذاری تصویر ارجاع یافته در خصوصیت src به صورت معمول میپردازند.
نکته: در بخش <head> سند شاهد خطی به صورت زیر هستیم:
که مرورگرهای قدیمی را وامیدارد تا از اندازه صفحه واقعی خود برای بارگذاری صفحههای وب استفاده کنند. برخی از مرورگرهای موبایل از عرض صفحه خود استفاده میکنند و به جای بارگذاری صفحه وب در اندازههای بزرگ اندازه صفحه را کاهش میدهند که فایده چندانی برای تصاویر یا طراحی واکنشگرا ندارد. در مورد این وضعیت در بخشهای بعدی این سری مقالات بیشتر صحبت خواهیم کرد.
برخی ابزارهای مفید توسعهدهنده در مرورگرها وجود دارند که به تعیین عرضهای ضروری اسلات و موارد دیگر کمک میکنند. زمانی که این موارد را محاسبه میکنیم، ابتدا نسخه غیر واکنشگرای مثال خود را که در ابتدای این مقاله ارائه شده است در یک برگه جدید مرورگر باز کنید. سپس به نمای طراحی واکنشگرا در مسیر Tools > Web Developer > Responsive Design View بروید تا امکان بررسی طرحبندی صفحه روی دستگاههای مختلف با اندازه صفحههای متفاوت را داشته باشید.
ما عرض صفحه را برابر با 320 پیکسل و سپس 480 پیکسل قرار دادیم و در هر مرحله به بخش DOM Inspector رفته و روی عنصر <img> کلیک کردیم، سپس به اندازه آن در برگه Box Model در سمت راست نمایشگر نگاه کردیم. بدین ترتیب عرض ذاتی تصاویر به دست میآید.

سپس میتوانید با تعیین عرض صفحه به مقدار دلخواه، بررسی کنید که آیا srcset کار میکند یا نه. بدین منظور به بخش Network Inspector بروید و سپس صفحه را مجدداً بارگذاری کنید. بدین ترتیب لیستی از فایلها را میبینید که دانلود میشوند تا صفحه وب ایجاد شود. در اینجا میتوانید ببینید که فایل تصویر انتخابی برای دانلود کدام است.
نکته: زمانی که مشغول تست صفحه روی مرورگر کروم هستید، باید زمانی که DevTools با رفتن به مسیر Settings > Preferences > Network باز شده است، کش را غیر فعال کنید، چون در غیر این صورت کروم تصاویری که قبلاً دانلود کرده را بارگذاری میکند و اهمیتی به تصاویری متناسبتر هستند نمیدهد.

اگر شما در وبسایت خود از چندین وضوح نمایشی پشتیبانی میکنید؛ اما همه افراد تصویرهای شما را در اندازه واقعی صفحه مشاهده میکنند، میتوانید با استفاده از srcset با x-descriptors و بدون sizes به مرورگر اعلام کنید که یک وضوح تصویر مناسب را انتخاب کند. نمونهای از آن را در ادامه مشاهده میکنید:

در این مثال، CSS زیر روی تصویر به طرزی اعمال شده است که عرضی برابر با 320 پیکسل روی صفحه خواهد داشت:
در این حالت خصوصیت sizes مورد نیاز نیست و مرورگر محاسبه میکند که نمایشگر کدام وضوح تصویر را دارد و مناسبترین تصویر را که در srcset ارجاع یافته است ارائه میکند. بنابراین اگر دستگاهی به صفحهای دسترسی پیدا کند که وضوح نمایش پایین/استاندارد دارد و در آن هر پیکسل نماینده یک پیکسل CSS است، تصویر elva-fairy-320w.jpg بارگذاری خواهد شد. اگر دستگاه وضوح تصویر بالایی داشته باشد و در آن برای هر پیکسل CSS دو پیکسل نمایشگر یا بیشتر وجود داشته باشد، تصویر elva-fairy-640w.jpg بارگذاری خواهد شد. تصویر 640 پیکسل حجمی به اندازه 93 کیلوبایت دارد، در حالی که تصویر 320 پیکسل 39 کیلوبایت حجم دارد.
اگر بخواهیم یادآوری بکنیم، مسئله Art Direction شامل تغییر دادن تصویر نمایش یافته برای ایجاد تناسب در اندازههای متفاوت نمایشی است. برای نمونه اگر یک تصویر منظره بزرگ باشد که فردی در میانه آن ایستاده است و در یک وبسایت روی مرورگر دسکتاپ نمایش مییابد، زمانی که این وبسایت روی مرورگر موبایل نمایش میابد، بد به نظر میآید، زیرا آن فرد واقعاً کوچک خواهد بود و به سختی دیده میشود. در چنین مواردی شاید واقعاً بهتر باشد که تصویر پرتره کوچکتری روی موبایل نمایش یابد که فرد را در حالت بزرگنمایی شده نمایش میدهد. عنصر <picture> به ما امکان میدهد که صرفاً این نوع از راهحل را پیادهسازی کنیم.
اگر به مثال ابتدای این نوشته بازگردیم، میبینیم که تصویر موجود در هدر نیاز شدیدی به Art Direction دارد.
این وضعیت را با استفاده از <picture> که مانند عناصر <video> و <audio> است اصلاح میکنیم. عنصر <picture> یک پوشش است که شامل چند عنصر <source> است و چند منبع متفاوت در اختیار مرورگر قرار میدهد تا انتخاب کند و البته پس از عنصر کاملاً مهم <img> میآید. با استفاده از این راهحل کد ما به صورت زیر درمیآید:
عناصر <source> شامل یک خصوصیت media هستند که شامل شرط رسانهای است و چنان که در مثال srcset دیدیم، این شرطها آزمونهایی هستند که تصمیم میگیرند کدام تصویر نمایش پیدا کند. نخستین تصویری که مقدار true بازگشت دهد نمایش خواهد یافت. در این حالت اگر عرض صفحه برابر با 799 پیکسل باشد، نخستین <source> عنصر تصویر نمایش پیدا خواهد کرد. اگر عرض صفحه برابر با 800 پیکسل یا بیشتر باشد، تصویر منبع دوم نمایش پیدا میکند.
خصوصیتهای srcset شامل مسیر تصویری هستند که باید نمایش پیدا کند. دقت داشته باشید چنان که در مورد <img> قبلاً دیدیم، <source> نیز یک خصوصیت srcset میگیرد که در آن چند تصویر ارجاع یافتهاند و یک خصوصیت sizes نیز دارد. بنابراین میتوانید چندین تصویر را از طریق عنصر <picture> ارائه کنید؛ اما در این صورت باید چندین وضوح تصویر نیز برای هر یک تعیین کنید. در عمل شما احتمالاً در اغلب موارد چنین چیزی را نمیخواهید.
در همه موارد، باید یک عنصر <img> ارائه کنید که دارای خصوصیتهای src و alt باشد و درست قبل از </picture> آمده باشد، چون در غیر این صورت هیچ تصویری نمایش پیدا نخواهد کرد. این عنصر حالت پیشفرض را تعیین میکند. این حالت وقتی اعمال میشود که هیچ شرط رسانهای مقدار true بازگشت ندهد و همچنین در مورد مرورگرهایی که از عنصر picture پشتیبانی نمیکنند به عنوان یک fallback عمل میکند.
این کد امکان نمایش یک تصویر مناسب را روی صفحههای عریض و همچنین نمایشگرهای کمعرض مانند تصویر زیر فراهم میسازد:


نکته: شما باید از خصوصیت media تنها در سناریوهای Art Direction استفاده کنید؛ اما زمانی که از media بهره میگیرید، شرطهای رسانه را درون خصوصیت sizes هم نیاورید.
زمانی که مرورگر شروع به بارگذاری یک صفحه میکند، ابتدا و پیش از آن که parser اصلی شروع به بارگذاری و تفسیر CSS و جاوا اسکریپت صفحه بکند، هر تصویری که وجود داشته باشد را دانلود (پیش بارگذاری) میکند. این یک تکنیک مفید است که به صورت میانگین موجب 20 درصد بهبود در زمان بارگذاری صفحه میشود. با این وجود، در مورد تصاویر واکنشگرا مفید نیست چون باید راهحلهایی مانند srcset پیاده سزای شو. بدین ترتیب برای نمونه نمیتوان عنصر <img> را بارگذاری درک د و سپس عرض صفحه را با استفاده از جاوا اسکریپت تشخیص داد و به صورت دینامیک منبع تصویر را در صورت نیاز به تصاویر کوکتر عوض کرد. چون در این زمان تصویر اصلی قبلاً بارگذاری شده است و با این کار تصویر کوچکتر نیز بارگذاری میشود که از نظر واکنشگرایی وضعیتی بدتر از قبل را رقم میزند.
چند قالب جدید تصویر مانند WebP و JPEG-2000 وجود دارند که میتوانند همزمان اندازه فایل کم و کیفیت بالا را داشته باشند. با این وجود پشتیبانی مرورگرها از این قالبهای تصویر پراکنده است.
عنصر <picture> امکان تداوم سرویسدهی در مرورگرهای قدمی را فراهم میکند. شما میتوانید انواع MIME آ درون خصوصیت type وارد کنید تا مرورگرها بتوانند بیدرنگ انواع فایلی را که پشتیبانی نمیکنند رد کنند:
در این یادگیری عملی، انتظار داریم که قوی و شجاع باشید و مسیر را برخلاف روال معمول این سری مقالات بدون کمک ما طی کنید، یا دستکم بخش عمده آن را به صورت مستقل طی کنید. از شما خواسته میشود که حالت Art Direction خودتان را برای صفحههای عریض و کمعرض با استفاده از <picture> پیادهسازی کنید و یک نمونه سوئیچ وضوح تصویر داشته باشید که در آن از srcset استفاده شده باشد. بدین منظور باید کارهای زیر را انجام دهید:
نکته: از بخش devtools مرورگر برای پیدا کردن اندازههای مورد نیاز، چنان که در متن مقاله اشاره کردیم استفاده کنید.
بدین ترتیب به پایان این مقاله با موضوع تصاویر واکنشگرا رسیدیم. امیدواریم از آشنا شدن با این تکنیکها لذت برده باشید. به عنوان جمعبندی اشاره میکنیم که در زمان بحث از واکنشگرایی دو مسئله وجود دارد که میخواهیم حل کنیم:
این مسئلهای که در آن میخواهیم تصاویر برش یافتهای را برای طرحبندیهای مختلف ارائه کنیم. برای نمونه یک تصویر چشمانداز که صحنه کاملی از یک طرحبندی دسکتاپ را نمایش نشان میدهد و یک تصویر پرتره که سوژه اصلی را در حالت بزرگنمایی شده در طرحبندی موبایل به نمایش میگذارد. این مسئله را با استفاده از عنصر <picture> میتوان حل کرد.
مسئلهای که در این حالت میخواهیم حل کنیم، این است که فایلهای تصاویر کوچکتری را روی دستگاههای با صفحه کمعرض نمایش دهیم، چون به تصاویر بزرگ که مناسب مرورگرهای دسکتاپ هستند نیاز ندارند. در این حالت به صورت گزینه بندی شده تصاویر با وضوح متفاوت را برای صفحههای با اندازه بزرگ و کوچک ارائه میکنیم. این مسئله را میتوان با استفاده از گرافیکهای برداری (تصاویر SVG) و همچنین خصوصیتهای srcset و sizes حل کرد.
در بخش بعدی این سری مقالات راهنمای جامع HTML به ارزیابی آموختههای خود در زمینه فایلهای چندرسانهای میپردازیم.
برای مطالعه قسمت بعدی از این مجموعه مطلب آموزشی روی لینک زیر کلیک کنید:
در زبان برنامهنویسی ++C نه تنها میتوان مقادیر را با ارجاع به یک تابع ارسال کرد، بلکه میتوان مقدار بازگشتی با ارجاع را نیز به دست آورد. برای درک این قابلیت، باید در مورد متغیرهای سراسری با در مورد متغیرهای سراسری که در مطالب قبلی معرفی کردیم آشنایی داشته باشید. برای مطالعه قسمت قبلی این مجموعه مطلب آموزشی میتوانید روی لینک زیر کلیک کنید:
بازگشتی با ارجاع
5
در برنامه فوق، نوع بازگشتی تابع ()test به صورت &int است. از این رو این تابع یک ارجاع از متغیر num بازگشت میدهد.
گزاره بازگشتی تابع به صورت زیر است:
return num;
برخلاف بازگشتیِ با مقدار، این گزاره مقدار متغیر num را بازگشت نمیدهد، بلکه خود متغیر یعنی آدرس آن را بازگشت میدهد. از این رو زمانی که متغیر بازگشت یابد، میتوان آن را به یک مقدار مثلاً به صورت زیر انتساب داد:
test() = 5;
بدین ترتیب مقدار 5 در متغیر num ذخیره میشود که روی صفحه نمایش پیدا میکند.
تابع معمولی مقدار بازگشت میدهد، اما این تابع چنین نیست. از این رو نمیتوان یک ثابت را از تابع بازگشت داد:
نمیتوان یک متغیر محلی را از این تابع بازگشت داد:
بدین ترتیب به پایان این بخش از سری مقالات راهنمای جامع ++C میرسیم.
منبع: فرادرس
در این مقاله با ابزار کشیدن و رها کردن انگولار 7 آشنا شده و شیوه استفاده از آن را که در کیت توسعه متریال ارائه شده است خواهیم آموخت.

انگولار یک فریمورک جاوا اسکریپت (تایپاسکریپت) برای ساخت وب اپلیکیشن و یا اپلیکیشنهای موبایل و دسکتاپ با بیش از 42000 ستاره گیتهاب است. این فریمورک از سوی تیم انگولار در گوگل نگهداری میشود و میزبان اعضای جامعه خود و سازمانهای مختلفی است. انگولار نسخه 7 به تازگی انتشار یافته است و یکی از قابلیتهای جالب آن ابزار «کشیدن و رها کردن» (Drag and Drop) در کیت توسعه کامپوننت است.
کیت توسعه کامپوننت به مجموعهای از ابزارها گفته میشود که رفتارها و کامپوننتهای رایج را با سبکهای تعاملی کاملاً منحصر به فرد و بدون نگرانی از انتخاب قالبهای مختلف پیادهسازی میکند. این کیت نوعی لایه تجریدی برای کتابخانه متریال انگولار ارائه میکند که هیچ سبکبندی خاصی برای طراحی متریال ندارد. این کیت روشهای منحصر به فردی برای اعمال خلاقیت در زمان ساخت کامپوننتهای انگولار ارائه میکند.
ابزار کشیدن و رها کردن یکی از رفتارهای رایج کیت توسعه کامپوننت است. این ابزار شامل راهنماهایی است که امکان بسیار مهم کشیدن و رها کردن را در بخشهای مختلف کامپوننت فراهم میسازد.
ماژول angular/cdk/drag-drop@ روشی در اختیار ما قرار میدهد که به سادگی و به روشی اعلانی اینترفیسهای کشیدن و رها کردن را با پشتیبانی از مواردی از قبیل کشیدن آزاد، ذخیرهسازی درون یک لیست، انتقال آیتمها بین لیستها، انیمیشن، دستگاههای لمسی، دستگیرههای کشیدن سفارشی، پیشنمایشها و placeholder-ها ارائه میکند. علاوه بر آن لیستهای افقی و قفل کردن در راستای یک محور از قابلیتهای دیگر این ابزار است.
در ادامه فهرستی از 4 چیز را میبینید که برای استفاده از ابزار کشیدن و رها کردن در فضای کاری انگولار 7 ضروری هستند.
// run the command in a terminal ng version
//cd to a preferred location // run the command below ng new dragdrop
ng add @angular/material

ابزار کشیدن و رها کردن روی اغلب آیتمهای لیست کار میکند. در این بخش یک لیست کوچک از هنرمندان پاپ میسازیم و سپس کارکرد کشیدن و رها کردن را به آن اضافه میکنیم.
فایل کامپوننت اپلیکیشن را باز کرده و آرایهای از هنرمندان را به صورت زیر به آن اضافه کنید:
در فایل HTML کامپوننت اپلیکیشن، کد HTML آماده را با دستور ngFor برای رندر کردن لیست عوض کنید.
سپس یک کد کوچک سبکبندی در فایل CSS کامپوننت اپلیکیشن به صورت زیر اضافه کنید:
اینک لیست هنرمندان پاپ سبکبندی و رندر شده و به سادگی در زمان کشیدن آیتمهای لیست به اطراف قابل مشاهده است.

اکنون لیست آماده است و به بررسی همه جنبههای عمده ابزار جدید کشیدن و رها کردن در کیت توسعه کامپوننت به شرح زیر میپردازیم:
صرفاً با افزودن دایرکتیو cdkDrag به یک رندر کننده آیتم لیست، آن آیتمهای لیست قابلیت کشیده شدن مییابند:

میبینیم که در این مرحله میتوان آیتمها را به هر جایی در DOM کشید. محدوده این کشیدن را میتوان با قرار دادن لیست درون یک div به نام cdkDropList به همان لیست محدود کرد.
اکنون که میتوانیم آیتمهای لیست را به هر جای DOM یا درون یک لیست بکشیم، میتوانیم پا را فراتر گذارده و ترتیب آیتمها را تغییر دهیم یا اساساً تلاش کنیم آیتمهای لیست را به سمت بالا یا پایین حرکت دهیم. به این منظور باید به رویداد cdkDropListDropped گوش دهیم و متد moveItemsInArray را برای ایجاد امکان مرتبسازی مجدد تعیین کنیم.
متد MoveItemsInArray سه پارامتر میگیرد:

نکته: به خاطر داشته باشید که CdkDragDrop ،moveItemInArray را از angular/cdk/drag-drop ایمپورت کنید.
اینک ما میتوانیم آیتمهای یک لیست را با استفاده از کشیدن و رها کردن مرتبسازی مجدد بکنیم. در این بخش یک گام فراتر گذاشته و تلاش میکنیم این بار آیتمها را بین دو لیست مجزا مرتبسازی کنیم. با استفاده از دایرکتیو cdkDropList میتوانیم یک یا چند عنصر cdkDropList یعنی div-ها را با قرار دادنشان در یک عنصر با خصوصیت cdkDropListGroup یا تنظیم مشخصه cdkDropListConnectedTo به هم اتصال دهیم.
مواردی که در کد فوق وجود دارند را به صورت زیر میتوان خلاصه کرد:
توضیح مواردی که در کد فوق وجود دارند:

در این مرحله از یک سبکبندی گذار برای فرایند کشیدن و رها کردن استفاده میکنیم. این ماژول از اعمال انیمیشن روی آیتمهای لیست در زمان مرتبسازی یک عنصر درون یک لیست پشتیبانی میکند و همچنین در زمان کشیدن عنصر به یک لیست میتوان از انیمیشن استفاده کرد. به مثال ساده زیر توجه کنید:

شاید این انیمیشن هنوز چندان روان نباشد، اما میتوانید جلوه گذار را با زمانی که هیچ گذاری وجود نداشت مقایسه کنید. اگر این راهنما را تا به این جا پیگیری کرده باشید، پوشه کامپوننت اپلیکیشن نهایی شما باید دقیقاً مانند زیر باشد:
در این مقاله یک ابزار جدید CDK انگولار 7 را معرفی کردیم که drag and drop نام دارد. همچنین مثالهایی عملی از شیوه استفاده از آن و ظرفیتهایی که برای ساخت تجربه کاربری عالی فراهم میسازد دیدیم. برای مطالعه بیشتر به مستندات CDK (+) مراجعه کنید. برای دیدن کد کامل پروژه نیز میتوانید به این صفحه گیتهاب (+) مراجعه کنید.
اگر این مطلب برای شما مفید بوده است، آموزشهای زیر ن
منبع: فرادرس
در این مقاله میخواهیم به بررسی روشهای ارسال فرم HTML از طریق جاوا اسکریپت بپردازیم. در بخش قبلی دیدیم که فرمهای HTML را میتوان به صورت یک درخواست HTML به روش اعلانی ارسال کرد. در این بخش نیز با روش آمادهسازی یک درخواست HTML برای ارسال از طریق جاوا اسکریپت آشنا میشویم. برای مطالعه بخش قبلی این نوشته به مطلب زیر مراجعه کنید:
از زمان معرفی open Web apps اینک استفاده از فرم های HTML در مقاصدی به جز فرم های معمولی که به صورت کاغذی پر میکنیم بسیار متداول شده است. بدین ترتیب رفتهرفته توسعهدهندگان شروع به دست گرفتن کنترل بیشتری روی فرایند انتقال دادهها کردهاند.
فرم HTML استاندارد، URL-ی را بارگذاری میکند که دادهها در آن ارسال میشوند، یعنی پنجره مرورگر برای بارگذاری یک صفحه کامل اقدام میکند. با این حال اجتناب از بارگذاری یک صفحه کامل موجب میشود که با پنهانسازی مشکلات و تأخیر شبکه، تجربه کاربری روانتری رقم بخورد.
اغلب UI-های مدرن از فرم های HTML برای گردآوری ورودیهای کاربر استفاده میکنند. زمانی که کاربر تلاش میکند دادهها را ارسال بکند، اپلیکیشن کنترل را به دست میگیرد و این دادهها را به صورت ناهمگام در پسزمینه ارسال میکند. در ادامه تنها بخشهایی از رابط کاربری که نیازمند تغییر هستند، بهروزرسانی میشوند.
فناوری ارسال دادههای دلخواه به صورت ناهمگام به نام AJAX شناخته میشود که اختصاری برای عبارت «جاوا اسکریپت و XML ناهمگام» (Asynchronous JavaScript And XML) است.
AJAX از شیء DOM به نام XMLHttpRequest یا به اختصار XHR استفاده میکند. این شیء میتواند درخواستهای HTTP بسازد، آنها را ارسال کند و نتایج را بازگشت دهد.
نکته: تکنیکهای قدیمیتر AJAX صرفاً روی XMLHttpRequest تکیه نداشتند. برای نمونه JSOAP با تابع ()eval ترکیب شده بود. این تکنیک نیز کار میکند، اما استفاده از آن توصیه نمیشود، زیرا مشکلات امنیتی جدی دارد. تنها دلیل برای استفاده از این تکنیک ممکن است این باشد که مرورگرهای قدیمی از XMLHttpRequest یا JSON پشتیبانی نمیکنند، اما چنین مرورگرهایی باید واقعاً قدیمی باشند. بنابراین سعی کنید از چنین تکنیکهایی استفاده کنید.
XMLHttpRequest از لحاظ تاریخی برای واکشی و ارسال XML به عنوان یک فرمت تبادل داده طراحی شده است. اما نه XML و نه JSON در انکودینگ درخواست دادههای فرم جای نمیگیرند. دادههای فرم (application/x-www-form-urlencoded) لیستهای انکودشده URL از جفتهای کلید/مقدار تشکیل میدهند. برای ارسال کردن دادههای باینری، درخواست HTTP به صورت multipart/form-data تغییر شکل مییابد.
اگر فرانتاند (کدی که در مرورگر اجرا میشود) و کد بکاند (کدی که روی سرور اجرا میشود) را کنترل کنید، میتوانید JSON/XML را ارسال کرده و به هر شکلی که دوست دارید آنها را پردازش کنید.
اما اگر میخواهید از سرویس شخص ثالث استفاده کنید؛ کار به این سادگی نیست. برخی سرویسها تنها دادههای فرم را میپذیرند. همچنین مواردی وجود دارند که استفاده از دادههای فرم سادهتر است. اگر دادهها به صورت جفتهای کلید/مقدار، یا دادههای باینری خام باشند، ابزارهای بکاند موجود میتوانند آن را بدون نیاز به هیچ کد اضافی مدیریت کنند.
اینک سؤالی که مطرح میشود، این است که روش ارسال این دادهها چگونه است؟ در بخش بعدی به این سؤال پاسخ میدهیم.
3 روش برای ارسال دادههای فرم وجود دارد که از تکنیکهای قدیمی تا شیء جدیدتر FormData را شامل میشود. در ادامه همه این موارد را به تفصیل مورد بررسی قرار میدهیم.
XMLHttpRequest سادهترین و مطمئنترین راه برای ایجاد درخواستهای HTTP محسوب میشود. برای ارسال دادههای فرم با استفاده از XMLHttpRequest باید ابتدا دادهها را از طریق انکودینگ URL آماده کنیم و از مشخصههای تعیین شده برای درخواستهای دادههای فرم پیروی نماییم. در ادامه مثال قبلی را بازنویسی میکنیم:
چنان که مشاهده میکنید، HTML در عمل تغییر نیافته است. با این حال، کد جاوا اسکریپت کاملاً متفاوت است:
نتیجه نهایی به صورت زیر است:
نکته: استفاده از XMLHttpRequest تحت همان «سیاست اصالت» (origin policy) است که در زمان ارسال دادهها به وبسایتهای شخص ثالث مورد استفاده قرار میگیرد. در مورد درخواستهای cross-origin به کنترل دسترسی CORS و HTTP نیاز داریم.
ساخت یک درخواست HTTP به صورت دستی ممکن است کار پیچیدهای باشد. خوشبختانه یک استاندارد مشخصه XMLHttpRequest روشی راحت و ساده برای مدیریت درخواستهای دادههای فرم با شیء FormData ارائه میکند.
شیء FormFata میتواند برای انتقال دادههای فرم یا برای به دست آوردن دادههای درون یک عنصر فرم جهت مدیریت برای ارسال کردن آن، مورد استفاده قرار گیرد. توجه کنید که اشیای FormFata «فقط-نوشتنی» هستند، یعنی میتوان آنها را تغییر داد، اما نمیتوان محتوای آنها را بازیابی کرد.
در ادامه دو مثال از روش استفاده از این اشیا ارائه شده است:
شما احتمالاً با این کد ساده HTML آشنا هستید:
نتیجه آن چنین است:
روش دیگری که برای استفاده از شیء FormData وجود دارد، بهرهگیری از عنصر <form> است. بدین ترتیب یک FormData ایجاد میشود که دادههای موجود در فرم را نمایش میدهد.
کد نمونه HYML آن چنین است:
اما جاوا اسکریپت کنترل را از فرم میگیرد:
نتیجه کار چنین است:
شما با استفاده از مشخصه elements فرم میتوانید لیستی از همه عناصر دادهای را در فرم به دست آورید و به صورت دستی آنها را یک به یک مدیریت کنید. بدین ترتیب کنترل بیشتری روی این فرایند پیدا میکنید.
قدیمیترین روش برای ارسال ناهمگام دادههای فرم، ساخت یک فرم با استفاده از API مربوط به DOM است که دادهها را در یک عنصر پنهان < iframe> ارسال میکند. برای دسترسی به نتیجه ارسال باید محتوای < iframe> را بازیابی کنید.
هشدار: شما باید از این روش اجتناب کنید. در زمان استفاده از سرویسهای شخص ثالث این تکنیک موجب بروز ریسکهای امنیتی میشود، زیرا شما را در معرض حملههای تزریق اسکریپت قرار میدهد. اگر از HTTPS استفاده میکنید، این تکنیک میتواند روی same origin policy تأثیر بگذارد که محتوای یک <iframe> را غیر قابل دسترسی میکند. با این حال این متد در صورت نیاز به پشتیبانی از مرورگرهای خیلی قدیمی ممکن است تنها گزینه موجود باشد.
به مثال زیر توجه کنید:
نتیجه کد فوق چنین است:
اگر از یک شیء FormData در فرمی با ویجتهای <input type=”file”> استفاده میکنید، دادهها به صورت خودکار پردازش خواهند شد. اما برای ارسال دادههای باینری به صورت دستی باید کار بیشتری انجام یابد.
منابع زیادی برای دادههای باینری روی وب مدرن وجود دارند که برای نمونه شامل FileReader ،Canvas و WebRTC هستند. متأسفانه برخی مرورگرهای قدیمی نمیتوانند به دادههای باینری دسترسی پیدا کنند و نیازمند استفاده از راهحلهای پیچیدهای هستند. بررسی این مرورگرهای قدیمی خارج از حوصله این مقاله است.
ارسال دادههای باینری با پشتیبانی از FormData کار سرراستی است. کافی است از متد ()append استفاده کنید. اگر این کار را به صورت دستی انجام دهید پیچیدهتر خواهد بود.
ما در مثال زیر از API به نام FileReader برای دسترسی به دادههای باینری استفاده کردیم و سپس درخواست دادههای چندبخشی فرم را به صورت دستی میسازیم:
چنان که مشاهده میکنید، کد HTML شامل یک <form> استاندارد است. در این کد هیچ اتفاق عجیبی نمیافتد. بخش اصلی کار در کد جاوا اسکریپت رخ میدهد:
نتیجه کد فوق چنین است:
بسته به مرورگری که استفاده میکنید، ارسال کردن دادهها از طریق جاوا اسکریپت میتواند کاری آسان یا دشوار باشد. شیء FormData عموماً پاسخگو است و روی مرورگرهای قدیمی نیز میتوان از یک polyfill برای آن استفاده کرد
منبع: فرادرس