طراحی سایت و برنامه نویسی

آموزش طراحی سایت و برنامه نویسی

طراحی سایت و برنامه نویسی

آموزش طراحی سایت و برنامه نویسی

ساخت اپلیکیشن ساده آب و هوا با React Native و Expo — از صفر تا صد

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 (+) نام دارد.

فهرست پیش‌نیازها

  • آشنایی با روش نوشتن کدهای جاوا اسکریپت
  • آشنایی با React
  • نصب Node.js روی سیستم محلی
  • برخی دستورهای npm ساده

همه موارد مورد نیاز این‌ها هستند. بنابراین در ادامه فرایند توسعه اپلیکیشن خود را آغاز می‌کنیم.

سرآغاز

Expo XDE را پس از نصب کردن باز کنید و روی Create New Project کلیک کنید:

Expo

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

Expo

Expo

Expo EDE

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

Expo
برای مشاهده تصویر در ابعاد اصلی روی آن کلیک کنید.

اگر از Mac استفاده می‌کنید، باید مطمئن شوید که Xcode روی سیستمتان نصب شده است. اگر از ویندوز استفاده می‌کنید، دستورالعمل‌های نصب اندروید استودیو برای اجرای شبیه‌ساز را پیگیری کنید.

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

Expo
برای مشاهده تصویر در ابعاد اصلی روی آن کلیک کنید.

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

Expo

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

Expo
برای مشاهده تصویر در ابعاد اصلی روی آن کلیک کنید.

پیام نمایش یافته در این صفحه کد ساده‌ای است که از سوی App.js در ریشه اپلیکیشن ما رندر شده است:

<Text> را به صورت زیر تغییر دهید:

در این مرحله مشاهده می‌کنید که خروجی رندر می‌شود و اپلیکیشن به صورت خودکار و آنی بارگذاری مجدد می‌شود. برای مشاهده تغییرات نیازی به رفرش کردن وجود دارد.

Expo

بدین ترتیب مرحله نخست آغاز کار را انجام داده‌ایم. در مرحله بعدی یک پروتوتایپ استاتیک از اپلیکیشن خود می‌سازیم تا ببینیم چه سر و شکلی خواهد داشت.

پروتوتایپ

در این مرحله نخستین صفحه اپلیکیشن خود را توسعه می‌دهیم که یک صفحه بارگذاری است. بدین منظور در فایل App.js یک «حالت محلی» (local state) تعریف کنید:

کد فوق اعلام می‌کند که وقتی حالت محلی شیء isLoading نادرست است، نام اپلیکیشن را باید نشان دهیم. این همان چیزی است که قصد داریم رندر کنیم. در ادامه و زمانی که داده‌ها را با موفقیت واکشی کردیم، به جای نمایش دادن نام اپلیکیشن، وضعیت آب و هوا را در این صفحه نمایش خواهیم داد. در حال حاضر، این پیام را بررسی می‌کنیم و بدین منظور نخست باید به این سؤال پاسخ دهیم که اگر اپلیکیشن ما در حالت بارگذاری باشد چه خواهد شد؟ متن پیام را به این صفحه اضافه می‌کنیم تا به کاربر نشان دهیم اپلیکیشن در حال واکشی کردن داده‌ها است.

هنگامی که اپلیکیشن ما کار بارگذاری داده‌ها از API را به پایان ببرد، حالت isLoading را به صورت False تنظیم می‌کنیم:

Expo

صفحه نخست

ما یک کامپوننت «آب و هوا» (Weather) در مسیر components/Weather.js./ تعریف می‌کنیم. کد قالب برای هر صفحه شرایط جوی، یکسان خواهد بود و به دو view تقسیم می‌شود که یکی هدر و دیگری بدنه است. ویوی هدر آیکون شرایط جوی و دما را نشان می‌دهد و ویوی بدنه متن مرتبط با شرایط جوی را نمایش خواهد داد.

در Weather.js، شروع به تعریف کردن دو کانتینر درون کانتینر اصلی می‌کنیم که یکی headerContainer و دیگری bodyContainer است. توجه داشته باشید که کامپوننت weather به صورت یک کلاس و نه یک تابع تعریف می‌شود تا props را دریافت کند و از این رو می‌تواند یک حالت را مدیریت کند.

ما از MaterialCommunityIcons استفاده خواهیم کرد که به همراه Expo به عنوان یک کتابخانه فرعی از کتابخانه humongous به نام vector-icons عرضه می‌شود:

بدین ترتیب اپلیکیشن ما پس از اتمام مرحله پروتوتایپ به صورت زیر در خواهد آمد:

Expo

واکشی کردن داده‌ها

برای واکشی داده‌ها به صورت آنی از API نقشه Open Weather (+) استفاده می‌کنیم، چون کاملاً مفید و سازگار است. برای ارتباط با این API باید یک کلید API داشته باشیم، یعنی باید یک حساب کاربری در سایت ایجاد کنیم تا کلید API را دریافت کنیم. توجه داشته باشید که فعال شدن کلید API مربوط به Open Weather دست‌کم 10 دقیقه طول می‌کشد.

در وب‌سایت به بخش API section بروید. چنان که می‌بینید نیازهای ما بر اساس داده‌های جوی حاضر تأمین می‌شود. ما قصد داریم کلید API را در فایل utils/WeatherAPIKey.js/. ذخیره کنیم.

طرز کار API مربوط به Open Weather چنین است که باید مختصات طول و عرض جغرافیایی را از روی مکان دستگاه به آن ارائه کنیم. سپس داده‌ها را از سرور آن به صورت یک شیء JSON واکشی می‌کنیم. زمان کار با سرور به دو چیز نیاز داریم که یکی دما و دیگری شرایط جوی است. ما باید این دو مقدار را در حالت محلی App.js ذخیره کنیم.

ایمپورت کلید API

در این مرحله کار خود را ایمپورت کردن کلید 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 را نیز به صورت زیر به‌روزرسانی کنید:

Expo

از آنجا که بخش دشوار کار که واکشی داده‌ها به صورت همزمان بود را انجام دادیم، اینک باید کاری کنیم که کامپوننت weather ما بر اساس مقادیری که دریافت می‌کند رفتاری دینامیک داشته باشد. این رفتار دینامیک با withweatherCondition مرتبط خواهد بود.

رفتار دینامیک

با استفاده از withweatherCondition می‌توانیم تغییراتی را در پس‌زمینه، عنوان، عنوان فرعی آیکون جوی خود تعریف کنیم. کار خود را با تعریف از پیش آماده شرایط جوی در یک فایل به نام utils/WeatherConditions.js./ آغاز می‌کنیم:

تعریف PropTypes

این شرایط جوی به وسیله API مربوط به Open Weather ارائه می‌شوند. سپس این فایل را در weather.js ایمپورت می‌کنیم. همچنین PropTypes را برای دو prop که از App.js دریافت می‌کنیم تعریف خواهیم کرد. به کد زیر توجه کنید:

بخش غالب کد منبع یکسان است. ما اینک برخی موارد را از طریق دسترسی به prop-های شرایط جوی به صورت دینامیک تغییر می‌دهیم که شامل پس‌زمینه، آیکون، نام شرایط جوی و عنوان فرعی آن می‌شود. همچنین می‌توانید تغییراتی بنا به دلخواه خود در استایل اپلیکیشن ایجاد کنید تا ظاهری مینیمال‌تر یا زیباتر بیابد.

Expo

نکته: پیش از آن که اپلیکیشن را روی دستگاه واقعی خود اجرا کنید، باید مطمئن شوید که دسترسی اینترنت و مکان روی دستگاه برای این اپلیکیشن فعال شده است. ما در این مقاله در مورد دسترسی‌های اپلیکیشن صحبت نکردیم، چون تا حدودی خارج از حیطه این مطلب به حساب می‌آید. برای مشاهده کد کامل این پروژه می‌توانید به این ریپوی گیت‌هاب (+) مراجعه کنید.

اگر این نوشته برای شما مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:

تصاویر واکنش گرا (Responsive) در HTML — راهنمای جامع

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

برای مطالعه قسمت قبلی این مجموعه مطلب می‌توانید روی لینک زیر کلیک کنید:

چرا باید از تصاویر واکنش گرا استفاده کنیم؟

سناریوی متداول زیر را تصور کنید. یک وب‌سایت معمولی می‌تواند شامل یک تصویر هدر و برخی تصاویر محتوایی در زیر هدر باشد. تصویر هدر به طور معمول کل عرض صفحه را پوشش می‌دهد و تصویر محتوا یک بخش (یا همه) عرض ستون محتوا را اشغال می‌کند. به تصویر زیر توجه کنید:

Responsive

این وضعیت روی یک دستگاه با صفحه عریض مانند لپ‌تاپ یا دسکتاپ به خوبی نمایش پیدا می‌کند. کد صفحه فوق به صورت زیر است:

ما در این بخش قصد نداریم کدهای CSS را مورد بررسی دقیقی قرار دهیم و صرفاً برخی موارد را در ادامه فهرست‌بندی کرده‌ایم:

  • عرض محتوای body صفحه برابر با 1200 پیکسل تنظیم شده است. در مواردی که عرض صفحه بالاتر از 1200 پیکسل باشد، محتوا این عرض را حفظ کرده در مرکز صفحه باقی می‌ماند. در صفحه‌هایی با عرض کمتر از 1200 پیکسل، ستون محتوا 100% صفحه را اشغال می‌کند.
  • تصویر هدر به این صورت تنظیم شده است که همواره در مرکز بخش هدر باقی بماند و مهم نیست که عرض این بخش چه قدر باشد. اگر سایت روی یک صفحه با عرض کمتر مشاهده شود، جزییات مهم (افراد درون تصویر) در مرکز تصویر باقی می‌مانند و همچنان قابل مشاهده هستند و بخش اضافی از دو طرف برش می‌خورد. ارتفاع این تصویر 200 پیکسل است.
  • تصاویر محتوا به این صورت تنظیم شده‌اند اگر که عنصر body از تصویر کوچک‌تر باشد، تصاویر شروع به جمع شدن می‌کنند تا همواره درون body جای بگیرند و از آن خارج نشوند.

دستگاه‌های با صفحات نمایش کوچک

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

Responsive

یکی از راه‌های برای بهبود این وضعیت آن است که نسخه برش یافته‌ای از تصویر را نمایش دهیم که وقتی سایت روی صفحه‌های کم‌عرض نمایش پیدا می‌کند، صرفاً جزییات مهم تصویر را نمایش دهد. تصویر دوم برش یافته نیز می‌تواند برای نمایش روی صفحه دستگاه‌هایی با عرض متوسط مانند تبلت استفاده شود. این مشکل به طور معمول به نام مسئله «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

srcset مجموع تصاویری که مرورگر می‌تواند از بین آن‌ها انتخاب کند را شامل می‌شود و اندازه هر تصویر را نیز نمایش می‌دهد. پیش از هر ویرگول موارد زیر را می‌نویسیم:

  1. یک نام فایل تصویر (elva-fairy-480w.jpg)
  2. یک «فاصله» (Space)
  3. عرض ذاتی تصویر به پیکسل (400w)؛ دقت کنید که از واحد w (و نه مقدار معمول px) استفاده شده است. این اندازه واقعی تصویر است که با بررسی فایل تصویر روی رایانه به دست می‌آید. برای نمونه در ویندوز می‌توانید روی تصویر راست کلیک کرده و آخرین گزینه properties را انتخاب کنید و در پنجره باز شده به برگه details بروید تا اندازه واقعی تصویر را ملاحظه کنید.

خصوصیت Sizes

Sizes مجموعه‌ای از «شرایط رسانه» (Media Condition) است؛ یعنی عرض صفحه را تعریف و تعیین می‌کند که هر کدام از شرط‌های فوق تا چه اندازه‌ای باید انتخاب شوند. این‌ها سرنخ‌هایی هستند که قبلاً در موردش صحبت کردیم. در این حالت، پیش از هر ویرگول موارد زیر را می‌نویسیم:

  1. یک شرط رسانه (max-width:480px) تعریف کنید که حالت ممکن صفحه را نشان می‌دهد. در این مورد اعلام می‌کنیم که «وقتی عرض صفحه 400 پیکسل یا کمتر باشد».
  2. یک «فاصله» (Space)
  3. عرض اسلات تصویر که در صورت برقرار بودن شرط رسانه انتخاب خواهد شد. (440px)

نکته: در مورد عرض اسلات باید یک طول مطلق (px ،em) یا طول نسبی صفحه (vw) ارائه کنید؛ اما امکان تعیین درصد وجود ندارد. ممکن است متوجه شده باشید که آخرین عرض اسلات شرط رسانه‌ای ندارد. دلیل این مسئله آن است که این مقدار پیش‌فرض است و هنگامی که هیچ شرط رسانه‌ای صحیح نباشد انتخاب می‌شود. مرورگر هر چیزی را که پس از اولین شرط سازگار بیابد نادیده می‌گیرد، بنابراین در مورد ترتیب‌بندی شرط‌های رسانه‌ای با احتیاط عمل کنید.

بدین ترتیب وقتی این خصوصیت‌ها تنظیم شوند، مرورگر به صورت زیر عمل خواهد کرد:

  1. به عرض دستگاه نگاه می‌کند.
  2. تعیین می‌کند که کدام شرط رسانه‌ای در لیست sizes برقرار است.
  3. به عرض اسلات ارائه شده برای آن شرط رسانه نگاه می‌کند.
  4. تصویر ارجاع یافته در لیست srcset را که نزدیک‌ترین مطابقت را با عرض اسلات انتخابی داشته باشد، بارگذاری می‌کند.

مرورگرهای قدیمی

این همه داستان است. بنابراین در این مرحله اگر یک مرورگر مناسب با اندازه صفحه 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 در سمت راست نمایشگر نگاه کردیم. بدین ترتیب عرض ذاتی تصاویر به دست می‌آید.

Responsive

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

نکته: زمانی که مشغول تست صفحه روی مرورگر کروم هستید، باید زمانی که DevTools با رفتن به مسیر Settings > Preferences > Network باز شده است، کش را غیر فعال کنید، چون در غیر این صورت کروم تصاویری که قبلاً دانلود کرده را بارگذاری می‌کند و اهمیتی به تصاویری متناسب‌تر هستند نمی‌دهد.

Responsive

Resolution Switching در موقعیت‌هایی با اندازه یکسان و وضوح‌های مختلف

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

Responsive

در این مثال، CSS زیر روی تصویر به طرزی اعمال شده است که عرضی برابر با 320 پیکسل روی صفحه خواهد داشت:

در این حالت خصوصیت sizes مورد نیاز نیست و مرورگر محاسبه می‌کند که نمایشگر کدام وضوح تصویر را دارد و مناسب‌ترین تصویر را که در srcset ارجاع یافته است ارائه می‌کند. بنابراین اگر دستگاهی به صفحه‌ای دسترسی پیدا کند که وضوح نمایش پایین/استاندارد دارد و در آن هر پیکسل نماینده یک پیکسل CSS است، تصویر elva-fairy-320w.jpg بارگذاری خواهد شد. اگر دستگاه وضوح تصویر بالایی داشته باشد و در آن برای هر پیکسل CSS دو پیکسل نمایشگر یا بیشتر وجود داشته باشد، تصویر elva-fairy-640w.jpg بارگذاری خواهد شد. تصویر 640 پیکسل حجمی به اندازه 93 کیلوبایت دارد، در حالی که تصویر 320 پیکسل 39 کیلوبایت حجم دارد.

Art Direction

اگر بخواهیم یادآوری بکنیم، مسئله Art Direction شامل تغییر دادن تصویر نمایش یافته برای ایجاد تناسب در اندازه‌های متفاوت نمایشی است. برای نمونه اگر یک تصویر منظره بزرگ باشد که فردی در میانه آن ایستاده است و در یک وب‌سایت روی مرورگر دسکتاپ نمایش می‌یابد، زمانی که این وب‌سایت روی مرورگر موبایل نمایش میابد، بد به نظر می‌آید، زیرا آن فرد واقعاً کوچک خواهد بود و به سختی دیده می‌شود. در چنین مواردی شاید واقعاً بهتر باشد که تصویر پرتره کوچک‌تری روی موبایل نمایش یابد که فرد را در حالت بزرگ‌نمایی شده نمایش می‌دهد. عنصر <picture> به ما امکان می‌دهد که صرفاً این نوع از راه‌حل را پیاده‌سازی کنیم.

اگر به مثال ابتدای این نوشته بازگردیم، می‌بینیم که تصویر موجود در هدر نیاز شدیدی به Art Direction دارد.

این وضعیت را با استفاده از <picture> که مانند عناصر <video> و <audio> است اصلاح می‌کنیم. عنصر <picture> یک پوشش است که شامل چند عنصر <source> است و چند منبع متفاوت در اختیار مرورگر قرار می‌دهد تا انتخاب کند و البته پس از عنصر کاملاً مهم <img> می‌آید. با استفاده از این راه‌حل کد ما به صورت زیر درمی‌آید:

بهره‌گیری از خصوصیت Media

عناصر <source> شامل یک خصوصیت media هستند که شامل شرط رسانه‌ای است و چنان که در مثال srcset دیدیم، این شرط‌ها آزمون‌هایی هستند که تصمیم می‌گیرند کدام تصویر نمایش پیدا کند. نخستین تصویری که مقدار true بازگشت دهد نمایش خواهد یافت. در این حالت اگر عرض صفحه برابر با 799 پیکسل باشد، نخستین <source> عنصر تصویر نمایش پیدا خواهد کرد. اگر عرض صفحه برابر با 800 پیکسل یا بیشتر باشد، تصویر منبع دوم نمایش پیدا می‌کند.

خصوصیت‌های srcset شامل مسیر تصویری هستند که باید نمایش پیدا کند. دقت داشته باشید چنان که در مورد <img> قبلاً دیدیم، <source> نیز یک خصوصیت srcset می‌گیرد که در آن چند تصویر ارجاع یافته‌اند و یک خصوصیت sizes نیز دارد. بنابراین می‌توانید چندین تصویر را از طریق عنصر <picture> ارائه کنید؛ اما در این صورت باید چندین وضوح تصویر نیز برای هر یک تعیین کنید. در عمل شما احتمالاً در اغلب موارد چنین چیزی را نمی‌خواهید.

در همه موارد، باید یک عنصر <img> ارائه کنید که دارای خصوصیت‌های src و alt باشد و درست قبل از </picture> آمده باشد، چون در غیر این صورت هیچ تصویری نمایش پیدا نخواهد کرد. این عنصر حالت پیش‌فرض را تعیین می‌کند. این حالت وقتی اعمال می‌شود که هیچ شرط رسانه‌ای مقدار true بازگشت ندهد و همچنین در مورد مرورگرهایی که از عنصر picture پشتیبانی نمی‌کنند به عنوان یک fallback عمل می‌کند.

این کد امکان نمایش یک تصویر مناسب را روی صفحه‌های عریض و همچنین نمایشگرهای کم‌عرض مانند تصویر زیر فراهم می‌سازد:

Responsive

Responsive

نکته: شما باید از خصوصیت media تنها در سناریوهای Art Direction استفاده کنید؛ اما زمانی که از media بهره می‌گیرید، شرط‌های رسانه را درون خصوصیت sizes هم نیاورید.

چرا نباید صرفاً از CSS با جاوا اسکریپت استفاده کنیم؟

زمانی که مرورگر شروع به بارگذاری یک صفحه می‌کند، ابتدا و پیش از آن که parser اصلی شروع به بارگذاری و تفسیر CSS و جاوا اسکریپت صفحه بکند، هر تصویری که وجود داشته باشد را دانلود (پیش بارگذاری) می‌کند. این یک تکنیک مفید است که به صورت میانگین موجب 20 درصد بهبود در زمان بارگذاری صفحه می‌شود. با این وجود، در مورد تصاویر واکنش‌گرا مفید نیست چون باید راه‌حل‌هایی مانند srcset پیاده سزای شو. بدین ترتیب برای نمونه نمی‌توان عنصر <img> را بارگذاری درک د و سپس عرض صفحه را با استفاده از جاوا اسکریپت تشخیص داد و به صورت دینامیک منبع تصویر را در صورت نیاز به تصاویر کوک‌تر عوض کرد. چون در این زمان تصویر اصلی قبلاً بارگذاری شده است و با این کار تصویر کوچک‌تر نیز بارگذاری می‌شود که از نظر واکنش‌گرایی وضعیتی بدتر از قبل را رقم می‌زند.

استفاده از قالب‌های مدرن تصویر

چند قالب جدید تصویر مانند WebP و JPEG-2000 وجود دارند که می‌توانند همزمان اندازه فایل کم و کیفیت بالا را داشته باشند. با این وجود پشتیبانی مرورگرها از این قالب‌های تصویر پراکنده است.

عنصر <picture> امکان تداوم سرویس‌دهی در مرورگرهای قدمی را فراهم می‌کند. شما می‌توانید انواع MIME آ درون خصوصیت type وارد کنید تا مرورگرها بتوانند بی‌درنگ انواع فایلی را که پشتیبانی نمی‌کنند رد کنند:

  • از خصوصیت media استفاده نکنید؛ مگر این که به یک Art Direction نیاز داشته باشید.
  • در عنصر <source> می‌توانید تنها به آن تصاویری ارجاع بدهید که نوع آن‌ها در type اعلان شده باشد.
  • همانند قبل، در صورت نیاز استفاده از لیست‌هایی که با ویرگول جداسازی شده‌اند با srcset و sizes مشکلی ندارد.

یادگیری عملی: پیاده‌سازی تصاویر واکنش‌گرا

در این یادگیری عملی، انتظار داریم که قوی و شجاع باشید و مسیر را برخلاف روال معمول این سری مقالات بدون کمک ما طی کنید، یا دست‌کم بخش عمده آن را به صورت مستقل طی کنید. از شما خواسته می‌شود که حالت Art Direction خودتان را برای صفحه‌های عریض و کم‌عرض با استفاده از <picture> پیاده‌سازی کنید و یک نمونه سوئیچ وضوح تصویر داشته باشید که در آن از srcset استفاده شده باشد. بدین منظور باید کارهای زیر را انجام دهید:

  1. کد ساده HTML بنویسید که موارد فوق را شامل می‌شود. برای شروع می‌توانید از مثال ارائه شده در ابتدای این نوشته کمک بگیرید.
  2. یک عکس چشم‌انداز عریض زیبا پیدا کنید که جزییات زیادی داشته باشد و آن را در جایی روی سیستم ذخیره کنید. یک نسخه با اندازه وب از این تصویر را با استفاده از یک ویرایشگر گرافیکی تهیه کنید و سپس آن را طوری برش بدهید که بخش کوچک‌تری از تصویر با جزییات اصلی و به حالت بزرگنمایی نمایش یابد. این تصویر دوم را در اندازه‌ای با حدود 480 پیکسل تنظیم کنید.
  3. از عنصر <picture> برای پیاده‌سازی یک سوئیچ کننده تصویر Art Direction استفاده کنید.
  4. چند فایل تصویر با اندازه‌های متفاوت ایجاد کنید که هر کدام تصویر یکسانی را نمایش بدهند.
  5. از srcset/size برای ایجاد یک مثال سوئیچ وضوح تصویر استفاده کنید و یا این که می‌توانید تصویر یکسانی را با وضوح‌های تصویر متفاوت یا اندازه‌های تصویر مختلف در عرض صفحه‌های گوناگون عرضه کنید.

نکته: از بخش devtools مرورگر برای پیدا کردن اندازه‌های مورد نیاز، چنان که در متن مقاله اشاره کردیم استفاده کنید.

سخن پایانی

بدین ترتیب به پایان این مقاله با موضوع تصاویر واکنش‌گرا رسیدیم. امیدواریم از آشنا شدن با این تکنیک‌ها لذت برده باشید. به عنوان جمع‌بندی اشاره می‌کنیم که در زمان بحث از واکنش‌گرایی دو مسئله وجود دارد که می‌خواهیم حل کنیم:

Art Direction

این مسئله‌ای که در آن می‌خواهیم تصاویر برش یافته‌ای را برای طرح‌بندی‌های مختلف ارائه کنیم. برای نمونه یک تصویر چشم‌انداز که صحنه کاملی از یک طرح‌بندی دسکتاپ را نمایش نشان می‌دهد و یک تصویر پرتره که سوژه اصلی را در حالت بزرگنمایی شده در طرح‌بندی موبایل به نمایش می‌گذارد. این مسئله را با استفاده از عنصر <picture> می‌توان حل کرد.

Resolution Switching

مسئله‌ای که در این حالت می‌خواهیم حل کنیم، این است که فایل‌های تصاویر کوچک‌تری را روی دستگاه‌های با صفحه کم‌عرض نمایش دهیم، چون به تصاویر بزرگ که مناسب مرورگرهای دسکتاپ هستند نیاز ندارند. در این حالت به صورت گزینه بندی شده تصاویر با وضوح متفاوت را برای صفحه‌های با اندازه بزرگ و کوچک ارائه می‌کنیم. این مسئله را می‌توان با استفاده از گرافیک‌های برداری (تصاویر SVG) و همچنین خصوصیت‌های srcset و sizes حل کرد.

در بخش بعدی این سری مقالات راهنمای جامع HTML به ارزیابی آموخته‌های خود در زمینه فایل‌های چندرسانه‌ای می‌پردازیم.

برای مطالعه قسمت بعدی از این مجموعه مطلب آموزشی روی لینک زیر کلیک کنید:

مقدار بازگشتی با ارجاع در ++C — راهنمای کاربردی

در زبان برنامه‌نویسی ++C نه‌ تنها می‌توان مقادیر را با ارجاع به یک تابع ارسال کرد، بلکه می‌توان مقدار بازگشتی با ارجاع را نیز به دست آورد. برای درک این قابلیت، باید در مورد متغیرهای سراسری با در مورد متغیرهای سراسری که در مطالب قبلی معرفی کردیم آشنایی داشته باشید. برای مطالعه قسمت قبلی این مجموعه مطلب آموزشی می‌توانید روی لینک زیر کلیک کنید:

مثال

بازگشتی با ارجاع

خروجی

5

در برنامه فوق، نوع بازگشتی تابع ()test به صورت &int است. از این رو این تابع یک ارجاع از متغیر num بازگشت می‌دهد.

گزاره بازگشتی تابع به صورت زیر است:

return num;

برخلاف بازگشتیِ با مقدار، این گزاره مقدار متغیر num را بازگشت نمی‌دهد، بلکه خود متغیر یعنی آدرس آن را بازگشت می‌دهد. از این رو زمانی که متغیر بازگشت یابد، می‌توان آن را به یک مقدار مثلاً به صورت زیر انتساب داد:

test() = 5;

بدین ترتیب مقدار 5 در متغیر num ذخیره می‌شود که روی صفحه نمایش پیدا می‌کند.

نکات مهمی که هنگام استفاده از بازگشت با ارجاع باید به خاطر داشت

تابع معمولی مقدار بازگشت می‌دهد، اما این تابع چنین نیست. از این رو نمی‌توان یک ثابت را از تابع بازگشت داد:

نمی‌توان یک متغیر محلی را از این تابع بازگشت داد:

بدین ترتیب به پایان این بخش از سری مقالات راهنمای جامع ++C می‌رسیم.

منبع: فرادرس


ساخت لیست های تعاملی با ابزار کشیدن و رها کردن انگولار ۷ — به زبان ساده

در این مقاله با ابزار کشیدن و رها کردن انگولار 7 آشنا شده و شیوه استفاده از آن را که در کیت توسعه متریال ارائه شده است خواهیم آموخت.

کشیدن و رها کردن

انگولار یک فریمورک جاوا اسکریپت (تایپ‌اسکریپت) برای ساخت وب اپلیکیشن و یا اپلیکیشن‌های موبایل و دسکتاپ با بیش از 42000 ستاره گیت‌هاب است. این فریمورک از سوی تیم انگولار در گوگل نگهداری می‌شود و میزبان اعضای جامعه خود و سازمان‌های مختلفی است. انگولار نسخه 7 به تازگی انتشار یافته است و یکی از قابلیت‌های جالب آن ابزار «کشیدن و رها کردن» (Drag and Drop) در کیت توسعه کامپوننت است.

کیت توسعه کامپوننت (CDK)

کیت توسعه کامپوننت به مجموعه‌ای از ابزارها گفته می‌شود که رفتارها و کامپوننت‌های رایج را با سبک‌های تعاملی کاملاً منحصر به فرد و بدون نگرانی از انتخاب قالب‌های مختلف پیاده‌سازی می‌کند. این کیت نوعی لایه تجریدی برای کتابخانه متریال انگولار ارائه می‌کند که هیچ سبک‌بندی خاصی برای طراحی متریال ندارد. این کیت روش‌های منحصر به فردی برای اعمال خلاقیت در زمان ساخت کامپوننت‌های انگولار ارائه می‌کند.

ابزار کشیدن و رها کردن

ابزار کشیدن و رها کردن یکی از رفتارهای رایج کیت توسعه کامپوننت است. این ابزار شامل راهنماهایی است که امکان بسیار مهم کشیدن و رها کردن را در بخش‌های مختلف کامپوننت فراهم می‌سازد.

ماژول angular/cdk/drag-drop@ روشی در اختیار ما قرار می‌دهد که به سادگی و به روشی اعلانی اینترفیس‌های کشیدن و رها کردن را با پشتیبانی از مواردی از قبیل کشیدن آزاد، ذخیره‌سازی درون یک لیست، انتقال آیتم‌ها بین لیست‌ها، انیمیشن، دستگاه‌های لمسی، دستگیره‌های کشیدن سفارشی، پیش‌نمایش‌ها و placeholder-ها ارائه می‌کند. علاوه بر آن لیست‌های افقی و قفل کردن در راستای یک محور از قابلیت‌های دیگر این ابزار است.

پیش از آغاز

در ادامه فهرستی از 4 چیز را می‌بینید که برای استفاده از ابزار کشیدن و رها کردن در فضای کاری انگولار 7 ضروری هستند.

  • آخرین نسخه از انگولار (نسخه 7)
// run the command in a terminal
ng version
  • یک اپلیکیشن انگولار 7
//cd to a preferred location
// run the command below
ng new dragdrop
  • نصب انگولار متریال روی اپلیکیشن فوق
ng add @angular/material
  • ایمپورت کردن ماژول Drag Drop در ماژول app به طوری که برای استفاده در اپلیکیشن انگولار به صورت زیر آماده باشد:

کشیدن و رها کردن

رندر کردن یک لیست

ابزار کشیدن و رها کردن روی اغلب آیتم‌های لیست کار می‌کند. در این بخش یک لیست کوچک از هنرمندان پاپ می‌سازیم و سپس کارکرد کشیدن و رها کردن را به آن اضافه می‌کنیم.

فایل کامپوننت اپلیکیشن را باز کرده و آرایه‌ای از هنرمندان را به صورت زیر به آن اضافه کنید:

در فایل HTML کامپوننت اپلیکیشن، کد HTML آماده را با دستور ngFor برای رندر کردن لیست عوض کنید.

سپس یک کد کوچک سبک‌بندی در فایل CSS کامپوننت اپلیکیشن به صورت زیر اضافه کنید:

اینک لیست هنرمندان پاپ سبک‌بندی و رندر شده و به سادگی در زمان کشیدن آیتم‌های لیست به اطراف قابل مشاهده است.

کشیدن و رها کردن

اکنون لیست آماده است و به بررسی همه جنبه‌های عمده ابزار جدید کشیدن و رها کردن در کیت توسعه کامپوننت به شرح زیر می‌پردازیم:

  • کشیدن و رها کردن مقدماتی
  • مرتب‌سازی
  • جابجایی آیتم‌ها بین لیست‌ها
  • انیمیشن

کشیدن و رها کردن مقدماتی

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

کشیدن و رها کردن

می‌بینیم که در این مرحله می‌توان آیتم‌ها را به هر جایی در DOM کشید. محدوده این کشیدن را می‌توان با قرار دادن لیست درون یک div به نام cdkDropList به همان لیست محدود کرد.

مرتب‌سازی

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

  • فایل app.component.html را با کد زیر به‌روزرسانی کنید:
  • فایل app.component.ts را با کد زیر به‌روزرسانی کنید:

متد MoveItemsInArray سه پارامتر می‌گیرد:

  • آرایه لیستی که کار مرتب‌سازی مجدد را اجرا می‌کند.
  • Event.previousIndex که مکان قبلی آیتم کشیده شده برای رها شدن است.
  • Event.CurrentIndex که مکان فعالی آیتم کشیده شده و رها شده است و می‌تواند با مکان قبلی عوض شود.

کشیدن و رها کردن

نکته: به خاطر داشته باشید که CdkDragDrop ،moveItemInArray را از angular/cdk/drag-drop ایمپورت کنید.

جابجایی آیتم‌ها بین لیست‌ها

اینک ما می‌توانیم آیتم‌های یک لیست را با استفاده از کشیدن و رها کردن مرتب‌سازی مجدد بکنیم. در این بخش یک گام فراتر گذاشته و تلاش می‌کنیم این بار آیتم‌ها را بین دو لیست مجزا مرتب‌سازی کنیم. با استفاده از دایرکتیو cdkDropList می‌توانیم یک یا چند عنصر cdkDropList یعنی div-ها را با قرار دادنشان در یک عنصر با خصوصیت cdkDropListGroup یا تنظیم مشخصه cdkDropListConnectedTo به هم اتصال دهیم.

  • در فایل app.component.html کد زیر را اضافه کنید:

مواردی که در کد فوق وجود دارند را به صورت زیر می‌توان خلاصه کرد:

  1. ما یک droplist جدید از خط 7 تا 11 اضافه کرده‌ایم و در این خطوط تلاش می‌کنیم یک لیست جدید را رندر کنیم.
  2. دو div مجزا را در یک div قرار داده و طوری سبک‌بندی می‌کنیم که flex را نمایش دهند و بدین ترتیب به صورت مجزا از هم درآیند.
  3. داده‌های droplist را برای هر لیست در خطوط 2 تا 7 تعیین می‌کنیم.
  4. لیستی را که هر لیست به آن وصل می‌شود در خطوط 3 تا 8 تعیین کرده‌ایم.
  5. در نهایت ID-هایی را روی لیست‌های drop ایجاد کرده‌ایم تا به انگولار اعلام کنیم که این موارد لیست‌های drop مجزا هستند.
  • در فایل app.component.ts کد زیر را اضافه کنید:

توضیح مواردی که در کد فوق وجود دارند:

  1. ما یک آرایه جدید alteArtists ایجاد کرده و آن را با داده‌های مناسب پر کردیم.
  2. یک گزاره if else برای تغییر متد moveinarray اضافه کردیم.
  3. بخش if شامل منطق برای زمانی است که یک آیتم لیست به یک لیست drop مجزا کشیده می‌شود.
  4. بخش else شامل منطق قدیمی برای مرتب‌سازی مجدد آیتم‌های لیست در لیست خاص خودش است.

کشیدن و رها کردن

انیمیشن

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

  • در فایل app.component.css:

کشیدن و رها کردن

شاید این انیمیشن هنوز چندان روان نباشد، اما می‌توانید جلوه گذار را با زمانی که هیچ گذاری وجود نداشت مقایسه کنید. اگر این راهنما را تا به این جا پیگیری کرده باشید، پوشه کامپوننت اپلیکیشن نهایی شما باید دقیقاً مانند زیر باشد:

  • فایل app.component.html
  • فایل app.component.ts
  • فایل app.component.css

سخن پایانی

در این مقاله یک ابزار جدید CDK انگولار 7 را معرفی کردیم که drag and drop نام دارد. همچنین مثال‌هایی عملی از شیوه استفاده از آن و ظرفیت‌هایی که برای ساخت تجربه کاربری عالی فراهم می‌سازد دیدیم. برای مطالعه بیشتر به مستندات CDK (+) مراجعه کنید. برای دیدن کد کامل پروژه نیز می‌توانید به این صفحه گیت‌هاب (+) مراجعه کنید.

اگر این مطلب برای شما مفید بوده است، آموزش‌های زیر ن

منبع: فرادرس


ارسال فرم HTML از طریق جاوا اسکریپت — راهنمای جامع

در این مقاله می‌خواهیم به بررسی روش‌های ارسال فرم 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 نیاز داریم.

استفاده از XMLHttpRequest و شیء FormData

ساخت یک درخواست HTTP به صورت دستی ممکن است کار پیچیده‌ای باشد. خوشبختانه یک استاندارد مشخصه XMLHttpRequest روشی راحت و ساده برای مدیریت درخواست‌های داده‌های فرم با شیء FormData ارائه می‌کند.

شیء FormFata می‌تواند برای انتقال داده‌های فرم یا برای به دست آوردن داده‌های درون یک عنصر فرم جهت مدیریت برای ارسال کردن آن، مورد استفاده قرار گیرد. توجه کنید که اشیای FormFata «فقط-نوشتنی» هستند، یعنی می‌توان آن‌ها را تغییر داد، اما نمی‌توان محتوای آن‌ها را بازیابی کرد.

در ادامه دو مثال از روش استفاده از این اشیا ارائه شده است:

استفاده از شیء مستقل FormData

شما احتمالاً با این کد ساده HTML آشنا هستید:

نتیجه آن چنین است:

استفاده از FormData متصل به یک عنصر فرم

روش دیگری که برای استفاده از شیء FormData وجود دارد، بهره‌گیری از عنصر <form> است. بدین ترتیب یک FormData ایجاد می‌شود که داده‌های موجود در فرم را نمایش می‌دهد.

کد نمونه HYML آن چنین است:

اما جاوا اسکریپت کنترل را از فرم می‌گیرد:

نتیجه کار چنین است:

شما با استفاده از مشخصه elements فرم می‌توانید لیستی از همه عناصر داده‌ای را در فرم به دست آورید و به صورت دستی آن‌ها را یک به یک مدیریت کنید. بدین ترتیب کنترل بیشتری روی این فرایند پیدا می‌کنید.

ساخت یک DOM در iframe پنهان

قدیمی‌ترین روش برای ارسال ناهمگام داده‌های فرم، ساخت یک فرم با استفاده از API مربوط به DOM است که داده‌ها را در یک عنصر پنهان < iframe> ارسال می‌کند. برای دسترسی به نتیجه ارسال باید محتوای < iframe> را بازیابی کنید.

هشدار: شما باید از این روش اجتناب کنید. در زمان استفاده از سرویس‌های شخص ثالث این تکنیک موجب بروز ریسک‌های امنیتی می‌شود، زیرا شما را در معرض حمله‌های تزریق اسکریپت قرار می‌دهد. اگر از HTTPS استفاده می‌کنید، این تکنیک می‌تواند روی same origin policy تأثیر بگذارد که محتوای یک <iframe> را غیر قابل دسترسی می‌کند. با این حال این متد در صورت نیاز به پشتیبانی از مرورگرهای خیلی قدیمی ممکن است تنها گزینه موجود باشد.

به مثال زیر توجه کنید:

نتیجه کد فوق چنین است:

کار با داده‌های باینری

اگر از یک شیء FormData در فرمی با ویجت‌های <input type=”file”> استفاده می‌کنید، داده‌ها به صورت خودکار پردازش خواهند شد. اما برای ارسال داده‌های باینری به صورت دستی باید کار بیشتری انجام یابد.

منابع زیادی برای داده‌های باینری روی وب مدرن وجود دارند که برای نمونه شامل FileReader ،Canvas و WebRTC هستند. متأسفانه برخی مرورگرهای قدیمی نمی‌توانند به داده‌های باینری دسترسی پیدا کنند و نیازمند استفاده از راه‌حل‌های پیچیده‌ای هستند. بررسی این مرورگرهای قدیمی خارج از حوصله این مقاله است.

ارسال داده‌های باینری با پشتیبانی از FormData کار سرراستی است. کافی است از متد ()append استفاده کنید. اگر این کار را به صورت دستی انجام دهید پیچیده‌تر خواهد بود.

ما در مثال زیر از API به نام FileReader برای دسترسی به داده‌های باینری استفاده کردیم و سپس درخواست داده‌های چندبخشی فرم را به صورت دستی می‌سازیم:

چنان که مشاهده می‌کنید، کد HTML شامل یک <form> استاندارد است. در این کد هیچ اتفاق عجیبی نمی‌افتد. بخش اصلی کار در کد جاوا اسکریپت رخ می‌دهد:

نتیجه کد فوق چنین است:

سخن پایانی

بسته به مرورگری که استفاده می‌کنید، ارسال کردن داده‌ها از طریق جاوا اسکریپت می‌تواند کاری آسان یا دشوار باشد. شیء FormData عموماً پاسخگو است و روی مرورگرهای قدیمی نیز می‌توان از یک polyfill برای آن استفاده کرد

منبع: فرادرس