والا آدم چاپلوسی نیستم ولی واقعا به شخصه اعتقاد دارم دوره MVC اینجا رو pluralsight باید صداگذاری کنه بزاره رو سایت خودش! :) واقعا بدون اغراق توی وب فارسی تا به حال همچین چیزی ندیده بودم.
بنده در حال ساخت جستجویی برای وب سایتی هستم. این جستجو بر روی جداول کتاب، نویسنده، مترجم و انتشارات انجام میشه و در صورتی که کاربر قسمتی از نام کتاب و نام نویسنده را وارد کند جستجو بر روی این دو فیلد که از دو جدول متفاوت هستند انجام میشود.
مشکل اینجاست که از آنجایی که دستوارت FTS بر روی یک جدول عمل می‌کنند و با توجه به پیچیدگی جستجو، شما چه راهی را برای کوئری گرفتن از چندین جدول (که ممکن است یک کتاب چند نویسنده هم داشته باشد) پیشنهاد می‌کنید.
بنده در حال حاضر تمام این جداول را در یک View قرار داده و فیلدهای چندمقداری را با Concat بوسیله " ، " در یک فیلد جای داده‌ام.
ممنون از راهنماییتون
مشکل اینجاست که از آنجایی که دستوارت FTS بر روی یک جدول عمل می‌کنند و با توجه به پیچیدگی جستجو، شما چه راهی را برای کوئری گرفتن از چندین جدول (که ممکن است یک کتاب چند نویسنده هم داشته باشد) پیشنهاد می‌کنید.
بنده در حال حاضر تمام این جداول را در یک View قرار داده و فیلدهای چندمقداری را با Concat بوسیله " ، " در یک فیلد جای داده‌ام.
ممنون از راهنماییتون
آقای نصیری سپاس.
مشکل حل شد, توضیح بدم اگر کسی مشکل من رو داشت دیگه نپرسه!
لینکی که دادید رو قبلا خوانده بودم ولی دقت نکردم در انتها ذکر کرده بودید تعریف فیلترهای سراسری
این کد رو متد Application_Start فایل Global.asax.cs اضافه کردم:
در همه جا اگر فرد لاگین کره بود می‌تونه دسترسی داشته باشه.
بعد در صفحه Home هم [AllowAnonymous] رو در ابتدا اضافه کردم تا بدون در نظر گرفتن لاگین اجازه دسترسی رو بده.
مشکل حل شد, توضیح بدم اگر کسی مشکل من رو داشت دیگه نپرسه!
لینکی که دادید رو قبلا خوانده بودم ولی دقت نکردم در انتها ذکر کرده بودید تعریف فیلترهای سراسری
این کد رو متد Application_Start فایل Global.asax.cs اضافه کردم:
GlobalFilters.Filters.Add(new System.Web.Mvc.AuthorizeAttribute());
بعد در صفحه Home هم [AllowAnonymous] رو در ابتدا اضافه کردم تا بدون در نظر گرفتن لاگین اجازه دسترسی رو بده.
یک نکته‌ی تکمیلی: ارتقاء به نگارش 3.1 و تغییر تنظیمات کوکی‌ها
مرورگر کروم، از نگارش 80 آن به بعد به همراه یک تغییر غیرسازگار با نگارش‌های قبلی آن است: از این پس تمام کوکی‌های آن در صورتیکه تنظیمات SameSite را نداشته باشند، به صورت SameSite=Lax تفسیر می‌شوند؛ که تغییر امنیتی فوق العاده‌ای است و سبب خواهد شد تا بسیاری از حملات مانند CSRF به طور کامل غیرعملی شوند. اما ... این مورد سبب از کار افتادن برنامه‌هایی خواهد شد که از سرویس‌هایی مانند IdentityServer استفاده می‌کنند. در یک چنین حالتی نیاز خواهید داشت برای رفع این مشکل، SameSite=None را تنظیم کنید.
اما SameSite چیست؟ تنظیم و خاصیت SameSite از سال 2016 به کوکی‌ها اضافه شد تا بتوان توسط آن در برابر حملات CSRF مقاومت کرد؛ مقادیر اولیه‌ی آن نیز Lax و Strict بودند. Lax به این معنا است که کوکی‌ها در حین مرور یک سایت، باید به صورت خودکار به سمت سرور همان سایت ارسال شوند؛ اما در حالت مرور سایت و هدایت از طریق سایت‌های دیگر به سایت ما، فقط درخواست‌های GET رسیده می‌توانند کوکی‌ها را نیز ارسال کنند. حالت Strict آن فقط کوکی‌های تنظیم شدهی درون یک سایت را معتبر شمرده و ارسال می‌کند. عدم تنظیم SameSite نیز مشکل خاصی را ایجاد نمی‌کرد. برای مثال اعمال اعتبارسنجی مبتنی بر OpenIdConnect مانند login/logout، نیاز دارند در طی یک درخواست POST، اطلاعاتی را به سایت خارجی درخواست کننده ارسال کنند. برای اینکه این عملیات به درستی صورت گیرد، می‌بایستی تنظیمات SameSite انجام نمی‌شد تا جابجایی کوکی‌ها بین دو دومین مختلف در حالت POST، بدون مشکل صورت می‌گرفت.
مشکل مهم! مقدار None را فقط مرورگر کروم متوجه میشود و جزو استاندارد SameSite نیست! در این استاندارد اگر مقدار SameSite تنظیم شود و مرورگر نتواند آن‌را تشخیص دهد (مانند iOS 12)، مقدار Strict را به عنوان مقدار دریافتی تنظیم می‌کند! به همین جهت برنامه‌ی شما باید بر اساس نوع مرورگر تصمیم‌گیری کند که آیا باید SameSite را به خروجی اضافه کند یا خیر.
وضعیت دات نت در این مورد: با به روز رسانی‌های جدید دات نت 4.7.2 و همچنین NET Core 2.1.، مقدار جدید None توسط برنامه (در CookieOptions) قابل تنظیم خواهد بود که سبب تولید SameSite=None میشود. به علاوه در NET Core 3.1.، مقدار SameSite.Unspecified را نیز میتوان تنظیم کرد که سبب خواهد شد تا خاصیت SameSite اصلا تنظیم نشود (اصلا به درخواست اضافه نشود؛ تا مرورگرهایی که نمی‌توانند مقدار None را تفسیر کنند، به اشتباه آن‌را به Strict تنظیم نکنند).
به صورت خلاصه: اگر برنامه‌ی شما از OpenIdConnect و یا IdentityServer استفاده نمی‌کند، هیچ تنظیمی را تغییر ندهید! تنظیم پیش‌فرض SameSite=Lax گوگل سبب میشود تا عملا حملات CSRF دیگر بر روی سایت شما قابل اجرا نباشد. اما اگر از IdentityServer استفاده می‌کنید، این تنظیم پیش‌فرض، سبب از کار افتادن امکان ارسال کوکی‌های حالت POST، به سایت‌های خارجی میشود و برنامه و سیستم شما از کار خواهد افتاد.
مرورگر کروم، از نگارش 80 آن به بعد به همراه یک تغییر غیرسازگار با نگارش‌های قبلی آن است: از این پس تمام کوکی‌های آن در صورتیکه تنظیمات SameSite را نداشته باشند، به صورت SameSite=Lax تفسیر می‌شوند؛ که تغییر امنیتی فوق العاده‌ای است و سبب خواهد شد تا بسیاری از حملات مانند CSRF به طور کامل غیرعملی شوند. اما ... این مورد سبب از کار افتادن برنامه‌هایی خواهد شد که از سرویس‌هایی مانند IdentityServer استفاده می‌کنند. در یک چنین حالتی نیاز خواهید داشت برای رفع این مشکل، SameSite=None را تنظیم کنید.
اما SameSite چیست؟ تنظیم و خاصیت SameSite از سال 2016 به کوکی‌ها اضافه شد تا بتوان توسط آن در برابر حملات CSRF مقاومت کرد؛ مقادیر اولیه‌ی آن نیز Lax و Strict بودند. Lax به این معنا است که کوکی‌ها در حین مرور یک سایت، باید به صورت خودکار به سمت سرور همان سایت ارسال شوند؛ اما در حالت مرور سایت و هدایت از طریق سایت‌های دیگر به سایت ما، فقط درخواست‌های GET رسیده می‌توانند کوکی‌ها را نیز ارسال کنند. حالت Strict آن فقط کوکی‌های تنظیم شدهی درون یک سایت را معتبر شمرده و ارسال می‌کند. عدم تنظیم SameSite نیز مشکل خاصی را ایجاد نمی‌کرد. برای مثال اعمال اعتبارسنجی مبتنی بر OpenIdConnect مانند login/logout، نیاز دارند در طی یک درخواست POST، اطلاعاتی را به سایت خارجی درخواست کننده ارسال کنند. برای اینکه این عملیات به درستی صورت گیرد، می‌بایستی تنظیمات SameSite انجام نمی‌شد تا جابجایی کوکی‌ها بین دو دومین مختلف در حالت POST، بدون مشکل صورت می‌گرفت.
با تغییر جدید گوگل، حالت پیش‌فرض SameSite که اجباری نبود، به صورت اجباری به Lax تنظیم شده‌است؛ اما برای حالاتی مانند OpenIdConnect، مقدار None را نیز اضافه کرده‌است. به همین جهت این نوع برنامه‌ها اگر از تنظیم SameSite=None استفاده نکنند، دیگر نمی‌توانند کوکی‌های درخواست‌های POST را بین دومین‌های مختلف جابجا کنند.
وضعیت دات نت در این مورد: با به روز رسانی‌های جدید دات نت 4.7.2 و همچنین NET Core 2.1.، مقدار جدید None توسط برنامه (در CookieOptions) قابل تنظیم خواهد بود که سبب تولید SameSite=None میشود. به علاوه در NET Core 3.1.، مقدار SameSite.Unspecified را نیز میتوان تنظیم کرد که سبب خواهد شد تا خاصیت SameSite اصلا تنظیم نشود (اصلا به درخواست اضافه نشود؛ تا مرورگرهایی که نمی‌توانند مقدار None را تفسیر کنند، به اشتباه آن‌را به Strict تنظیم نکنند).
به صورت خلاصه: اگر برنامه‌ی شما از OpenIdConnect و یا IdentityServer استفاده نمی‌کند، هیچ تنظیمی را تغییر ندهید! تنظیم پیش‌فرض SameSite=Lax گوگل سبب میشود تا عملا حملات CSRF دیگر بر روی سایت شما قابل اجرا نباشد. اما اگر از IdentityServer استفاده می‌کنید، این تنظیم پیش‌فرض، سبب از کار افتادن امکان ارسال کوکی‌های حالت POST، به سایت‌های خارجی میشود و برنامه و سیستم شما از کار خواهد افتاد.
با سلام. من در پروژه DNTIdentity برای تنظیمات لاگین کاربران غیر وبی طبق پروژه اعتبارسنجی مبتنی بر کوکی‌ها در ASP.NET Core 2.0 بدون استفاده از سیستم Identity تنظیمات انجام دادم. و لاگین به درستی انجام میگیرد ولی مشکل اینجاس که اگه بخوام توی سایت به صورت پیش فرض لاگین کنم خطای زیر را می‌دهد. یعنی میخواد با خود اون لاگینی که برای کاربران غیر وبی ساختم وارد بشود. میخواستم بدونم آیا میشود تنظیم کرد که برای ورود کاربران غیر وبی با api/account و برای خود سایت با account ای در خود پروژه پیاده سازی شده است وارد شوند
{"error":{"code":"UnsupportedApiVersion","message":"The HTTP resource that matches the request URI 'http://localhost:45225/api/account/login?ReturnUrl=%2Fidentity%2Fhome' does not support HTTP method 'GET'."}} 
حالتی را در نظر بگیرید که سرویس‌های یک برنامه در آدرسی مشخص هاست شده اند. اگر اعتبار سنجی برای این سرویس‌ها در نظر گرفته نشود به راحتی میتوان با در اختیار داشتن آدرس مورد نظر تمام سرویس های برنامه را فراخوانی کرد و اگر رمزگذاری اطلاعات بر روی سرویس‌ها فعال نشده باشد میتوان تمام اطلاعات این سرویس‌ها را به راحتی به دست آورد. کمترین تلاش در این مرحله برای پیاده سازی امنیت این است که برای فراخوانی هر سرویس حداقل یک شناسه و رمز عبور چک شود و فقط در صورتی که فراخوانی سرویس همراه با شناسه و رمز عبور درست بود اطلاعات در اختیار کلاینت قرار گیرد. قصد داریم طی یک مثال این مورد را بررسی کنیم:
ابتدا یک پروژه با دو Console Application با نام های Service و Client ایجاد کنید. سپس در پروژه Service یک سرویس به نام BookService ایجاد کنید و کدهای زیر را در آن کپی نمایید:
Contract مربوطه به صورت زیر است:
کدهای مربوط به سرویس:
فایل Program در پروژه Service را باز نمایید و کدهای زیر را که مربوط به hosting سرویس مورد نظر است در آن کپی کنید:
بر اساس کدهای بالا، سرویس BookService در آدرس http://localhost/BookService هاست میشود. نوع Binding نیز BasicHttpBinding انتخاب شده است.
حال نوبت به پیاده سازی سمت کلاینت می‌رسد. فایل Program سمت کلاینت را باز کرده و کدهای زیر را نیز در آن کپی نمایید:
در کدهای عملیات ساخت ChannelFactory برای برقراری اطلاعات با سرویس مورد نظر انجام شده است. پروژه را Build نمایید و سپس آن را اجرا کنید.
خروجی زیر مشاهده میشود:
تغییرات اعمال شده:
ابتدا نوع Security در Binding را به حالت TransportCredentialOnly تنظیم کردیم. در یک جمله هیچ گونه تضمینی برای صحت اطلاعات انتقالی در این حالت وجود ندارد و فقط یک اعتبار سنجی اولیه انجام خواهد شد. در نتیجه هنگام استفاده از این حالت باید با دقت عمل نمود و نباید فقط به پیاده سازی این حالت اکتفا کرد.( Encryption اطلاعات سرویس‌ها مورد بحث این پست نیست)
ClientCredentialType نیز باید به حالت Basic تنظیم شود. در WCF اعتبار سنجی به صورت پیش فرض در حالت Windows است (بعنی UserNamePasswordValidationMode برابر مقدار Windows است و اعتبار سنجی بر اساس کاربر انجام میشود) . این مورد باید به مقدار Custom تغییر یابد. در انتها نیز باید مدل اعتبار سنجی دلخواه خود را به صورت زیر پیاده سازی کنیم:
در پروژه سرویس یک کلاس به نام CustomUserNamePasswordValidator بسازید و کدهای زیر را در آن کپی کنید:
Validator مورد نظر از کلاسی abstract به نام UserNamePasswordValidator ارث می‌برد، در نتیجه باید متد abstract به نام Validate را override نماید. در بدنه این متد شناسه و رمز عبور با یک مقدار پیش فرض چک می‌شوند و در صورت عدم درستی این پارارمترها یک استثنا پرتاب خواهد شد.
تغییرات مورد نیاز سمت کلاینت:
اگر در این حالت پروژه را اجرا نمایید از آن جا که از این به بعد، درخواست‌ها سمت سرور اعتبار سنجی می‌شوند در نتیجه با خطای زیر روبرو خواهید شد:
توسط دستور زیر، مقدار شناسه و رمز عبور به درخواست اضافه میشود.
در اینجا UserName و Password اشتباه مقدار دهی شده اند تا روش کار Validator مورد بررسی قرار گیرد. حال اگر پروژه را اجرا نمایید خواهید دید که در Validator مورد نظر، عملیات اعتبار سنجی به درستی انجام میشود:
دریافت سورس مثال بالا
ابتدا یک پروژه با دو Console Application با نام های Service و Client ایجاد کنید. سپس در پروژه Service یک سرویس به نام BookService ایجاد کنید و کدهای زیر را در آن کپی نمایید:
Contract مربوطه به صورت زیر است:
[ServiceContract]
public interface IBookService
{
[OperationContract]
int GetCountOfBook();
} [ServiceBehavior(IncludeExceptionDetailInFaults = true)]
public class BookService : IBookService
{
public int GetCountOfBook()
{
return 10;
}
} class Program
{
static void Main(string[] args)
{
ServiceHost host = new ServiceHost(typeof(BookService));
var binding = new BasicHttpBinding();
host.AddServiceEndpoint(typeof(IBookService), binding, "http://localhost/BookService");
host.Open();
Console.Write("BookService host");
Console.ReadKey();
}
} حال نوبت به پیاده سازی سمت کلاینت می‌رسد. فایل Program سمت کلاینت را باز کرده و کدهای زیر را نیز در آن کپی نمایید:
static void Main(string[] args)
{
Thread.Sleep(2000);
BasicHttpBinding binding = new BasicHttpBinding();
ChannelFactory<IBookService> channel = new ChannelFactory<IBookService>(binding, new EndpointAddress("http://localhost/BookService"));
Console.WriteLine("Count of book: {0}", channel.CreateChannel().GetCountOfBook());
Console.ReadKey();
} خروجی زیر مشاهده میشود:
تا اینجا هیچ گونه اعتبار سنجی انجام نشد. برای پیاده سازی اعتبار سنجی باید یک سری تنظیمات بر روی Binding و Hosting سمت سرور و البته کلاینت بر قرار شود. فایل Program پروزه Service را باز نمایید و محتویات آن را به صورت زیر تغییر دهید:
static void Main(string[] args)
{
ServiceHost host = new ServiceHost(typeof(BookService));
var binding = new BasicHttpBinding();
binding.Security = new BasicHttpSecurity();
binding.Security.Mode = BasicHttpSecurityMode.TransportCredentialOnly;
binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Basic;
host.Credentials.UserNameAuthentication.UserNamePasswordValidationMode = System.ServiceModel.Security.UserNamePasswordValidationMode.Custom;
host.Credentials.UserNameAuthentication.CustomUserNamePasswordValidator = new CustomUserNamePasswordValidator();
host.AddServiceEndpoint(typeof(IBookService), binding, "http://localhost/BookService");
host.Open();
Console.Write("BookService host");
Console.ReadKey();
} ابتدا نوع Security در Binding را به حالت TransportCredentialOnly تنظیم کردیم. در یک جمله هیچ گونه تضمینی برای صحت اطلاعات انتقالی در این حالت وجود ندارد و فقط یک اعتبار سنجی اولیه انجام خواهد شد. در نتیجه هنگام استفاده از این حالت باید با دقت عمل نمود و نباید فقط به پیاده سازی این حالت اکتفا کرد.( Encryption اطلاعات سرویس‌ها مورد بحث این پست نیست)
ClientCredentialType نیز باید به حالت Basic تنظیم شود. در WCF اعتبار سنجی به صورت پیش فرض در حالت Windows است (بعنی UserNamePasswordValidationMode برابر مقدار Windows است و اعتبار سنجی بر اساس کاربر انجام میشود) . این مورد باید به مقدار Custom تغییر یابد. در انتها نیز باید مدل اعتبار سنجی دلخواه خود را به صورت زیر پیاده سازی کنیم:
در پروژه سرویس یک کلاس به نام CustomUserNamePasswordValidator بسازید و کدهای زیر را در آن کپی کنید:
public class CustomUserNamePasswordValidator : UserNamePasswordValidator
{
public override void Validate(string userName, string password)
{
if (userName != "Masoud" || password != "Pakdel")
throw new SecurityException("Incorrect userName or password");
}
} تغییرات مورد نیاز سمت کلاینت:
اگر در این حالت پروژه را اجرا نمایید از آن جا که از این به بعد، درخواست‌ها سمت سرور اعتبار سنجی می‌شوند در نتیجه با خطای زیر روبرو خواهید شد:
این خطا از آن جا ناشی میشود که تنظیمات کلاینت و سرور از نظر امنیتی با هم تناسب ندارد. در نتیجه باید تنظیمات Binding کلاینت و سرور یکی شود. برای این کار کد زیر را به فایل Program سمت کلاینت اضافه می‌کنیم:
static void Main(string[] args)
{
Thread.Sleep(2000);
BasicHttpBinding binding = new BasicHttpBinding();
binding.Security = new BasicHttpSecurity();
binding.Security.Mode = BasicHttpSecurityMode.TransportCredentialOnly;
binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Basic;
ChannelFactory<IBookService> channel = new ChannelFactory<IBookService>(binding, new EndpointAddress("http://localhost/BookService"));
channel.Credentials.UserName.UserName = "WrongUserName";
channel.Credentials.UserName.Password = "WrongPassword";
Console.WriteLine("Count of book: {0}", channel.CreateChannel().GetCountOfBook());
Console.ReadKey();
} channel.Credentials.UserName.UserName = "WrongUserName"; channel.Credentials.UserName.Password = "WrongPassword";
دریافت سورس مثال بالا
با سلام در مورد مطلب مفیدتون
اگر بخواهیم سطوح دسترسی رو روی این گرید تعریف کنیم به چه صورت می‌تونیم عمل کنیم منظورم به یک کاربر اجازه ثبت بدیم و یا فقط بتونه اطلاعات را ببینه ولی نتواند ویرایش کند ممنون
اگر بخواهیم سطوح دسترسی رو روی این گرید تعریف کنیم به چه صورت می‌تونیم عمل کنیم منظورم به یک کاربر اجازه ثبت بدیم و یا فقط بتونه اطلاعات را ببینه ولی نتواند ویرایش کند ممنون
مدل کردن داده در MongoDB
داده در MongoDB شمای منعطفی دارد. سندها در یک مجموعه به تعدادی از فیلدها با ساختاری شبیه به هم نیازی ندارند و فیلدهای مشترک در یک سند مجموعه ممکن است نوع‌های داده‌ی متفاوتی را نگهداری کنند.
برخی ملاحظات هنگام طراحی شمای در MongoDB
- شمای خود را بر اساس نیازمندی‌های کاربر طراحی کنید.
- آبجکت هایی را که از آنها باهم استفاده می‌کنید، داخل یک سند ترکیب کنید؛ درغیر اینصورت آنها را جدا کنید (اما مطمئن شوید که نباید نیازی به استفاده از Join باشد).
- داده را بصورت محدود تکثیر کنید؛ چون فضای دیسک ارزانتر است از محاسبه زمان.
- عمل Join را هنگام ذخیره کردن انجام دهید، نه موقع خواندن.
- شمای خود را برای بیشترین موارد استفاده بهینه کنید.
- تجمع‌های پیچیده (Complex Aggregation) را در شمای انجام دهید.
مثال
فرض کنید یک کاربر نیاز به طراحی یک پایگاه داده برای وب سایت خود دارد. تفاوت‌های طراحی شمای بین RDBMS و MongoDB را در ادامه ملاحظه خواهید کرد. وب سایت نیازمندهای زیر را دارد:
- هر پست یک عنوان یکتا، توضیحات و آدرس اینترنتی دارد.
- هر پست می‌تواند یک یا چند برچسب داشته باشد.
- هر پست نام نویسنده و تعداد Likeها را دارد.
- هر پست تعدادی نظر معین را توسط کاربران همراه با نامشان، پیام، تاریخ ثبت و تعداد Likeها، دارد.
- در هر پست صفر یا چند نظر وجود دارد.
در طراحی شمای توسط RDMBS برای نیازمندی‌های فوق، حداقل سه جدول نیاز است.
درحالیکه در طراحی شمای توسط MongoDB یک مجموعه از پست را با ساختار زیر خواهیم داشت:
{
_id: POST_ID
title: TITLE_OF_POST,
description: POST_DESCRIPTION,
by: POST_BY,
url: URL_OF_POST,
tags: [TAG1, TAG2, TAG3],
likes: TOTAL_LIKES,
comments: [
{
user:'COMMENT_BY',
message: TEXT,
dateCreated: DATE_TIME,
like: LIKES
},
{
user:'COMMENT_BY',
message: TEXT,
dateCreated: DATE_TIME,
like: LIKES
}
]
} 
اگر بعنوان فردی که روزانه بیش از 300 عنوان خبری مربوط به آی‌تی را مانند دیگر توسعه‌دهندگان، قسمتی از فعالیت روزانه‌ی خود کرده‌اید، مطمئنا بدنبال راه‌های ساده‌ی اشتراک گذاری و یا به قول آقای هنسلمن TIf this thenhat یا باختصار IFTT هستید. من برای مرور و دسته بندی فیدها از فیدخوان Inoreader.com (دارای یک API برای توسعه ) استفاده می‌کنم و برای اشتراک مطالب در این سایت از امکان موجود در هر دو سایت، استفاده می‌کنم.
در سایت جاری و در قسمت ارسال لینک‌های خبری، امکانی فراهم شده‌است تا کسانیکه از فایرفاکس استفاده می‌کنند بتوانند به راحتی صفحه‌ی در حال تماشا را برای اشتراک ارسال کنند. تصویر زیر قسمتی از صفحه‌ی ارسال لینک‌های خبری است که دکمه‌ی اشتراک فایرفاکس در آن وجود دارد:
در Inoreader نیز میتوان برای اشتراک آیتم‌ها، لینکی سفارشی را ایجاد و استفاده کرد تا کار اشتراک گذاری به راحتی در تمام مرورگرهای متداول و نه فقط فایرفاکس، انجام پذیرد. به این صورت که در گوشه‌ی سمت راست و پایین آیتم باز شده، تعداد زیادی از شبکه‌های اجتماعی برای اشتراک وجود دارند و نیز قسمتی هم برای معرفی یک Custom Site:
که برای تعریف یک مقصد اشتراک، پارامترهای زیر را در اختیار می‌گذارد:
[TITLE]: عنوان آیتم با انکدینگ
[TITLE_NOENC]: عنوان آیتم بدون انکدینگ
[URL]: آدرس آیتم
[CONTENT]: محتوای آیتم
[SOURCE]: منبع، که در اینجا کلمه‌ی Inoreader جایگزین میشود.
حالا با استفاده از الگوی معرفی شدهی لینک اشتراک سایت DNT و جایگزینی با آیتمهای بالا میتوان یک Custom Site را به Inoreader اضافه کرد:
که البته همانطور که مشخص است سایت جاری فقط دو پارامتر از پنج پارامتر را قبول می‌کند (پارامترهای دارای encoding):
حالا این مورد نیز به لیست اشتراک گذاری در Inoreader اضافه شده و می‌توانید نتیجه‌ی تست آن را در زیر ببینید:
در سایت جاری و در قسمت ارسال لینک‌های خبری، امکانی فراهم شده‌است تا کسانیکه از فایرفاکس استفاده می‌کنند بتوانند به راحتی صفحه‌ی در حال تماشا را برای اشتراک ارسال کنند. تصویر زیر قسمتی از صفحه‌ی ارسال لینک‌های خبری است که دکمه‌ی اشتراک فایرفاکس در آن وجود دارد:
javascript:location.href='https://www.dntips.ir/dailylinks?url='+encodeURIComponent(location.href)+'&title='+encodeURIComponent(document.title)
که برای تعریف یک مقصد اشتراک، پارامترهای زیر را در اختیار می‌گذارد:
[TITLE]: عنوان آیتم با انکدینگ
[TITLE_NOENC]: عنوان آیتم بدون انکدینگ
[URL]: آدرس آیتم
[CONTENT]: محتوای آیتم
[SOURCE]: منبع، که در اینجا کلمه‌ی Inoreader جایگزین میشود.
حالا با استفاده از الگوی معرفی شدهی لینک اشتراک سایت DNT و جایگزینی با آیتمهای بالا میتوان یک Custom Site را به Inoreader اضافه کرد:
https://www.dntips.ir/dailylinks?url=[URL]&title=[TITLE]
حالا این مورد نیز به لیست اشتراک گذاری در Inoreader اضافه شده و می‌توانید نتیجه‌ی تست آن را در زیر ببینید:
در قسمت قبل، نحوه‌ی برپایی و تنظیمات اولیه‌ی کتابخانه‌ی مسیریابی react-router-dom را بررسی کردیم. در ادامه نحوه‌ی دریافت پارامترهای مسیریابی و سایر جزئیات این کتابخانه را مرور می‌کنیم.
دریافت پارامترهای مسیریابی
گاهی از اوقات نیاز به ارسال پارامترهایی به مسیریابی‌های تعریف شده‌است. برای مثال در لیست محصولات تعریف شده، بسته به انتخاب هر کدام، باید id متناظری نیز در URL نهایی ظاهر شود. به این Id، یک Route parameter گفته میشود. برای پیاده سازی این نیازمندی به صورت زیر عمل می‌کنیم:
در فایل app.js، یک مسیریابی جدید را برای نمایش جزئیات یک محصول اضافه می‌کنیم:
در اینجا برای تعریف یک پارامتر مسیریابی، آن‌را با : شروع می‌کنیم؛ مانند id:، در مسیریابی جدید فوق. البته امکان تعریف چندین پارامتر هم در اینجا وجود دارد؛ مانند تعریف پارامترهای سال و ماه برای مسیریابی مطالب. به علاوه چون این نوع مسیریابی‌ها ویژه‌تر هستند، باید در ابتدا قرارگیرند. برای مثال اگر مسیریابی products/ را در اول لیست قرار دهیم، دیگر کار به انتخاب products/:id/ نخواهد رسید.
کامپوننت جدید src\components\productDetails.jsx نیز به صورت زیر تعریف شده‌است:
پس از این تغییرات و ذخیره سازی برنامه، با بارگذاری مجدد برنامه در مرورگر، ابتدا صفحه‌ی products را از منوی راهبری سایت انتخاب کرده و سپس بر روی یکی از محصولات لیست شده کلیک می‌کنیم. سپس در افزونه‌ی react developer tools، کامپوننت نمایش داده شدهی ProductDetails را انتخاب می‌کنیم:
در اینجا با گشودن اطلاعات خاصیت match تزریق شدهی به کامپوننت ProductDetails، میتوان اطلاعاتی مانند پارامترهای دریافتی مسیریابی را دقیقا مشاهده کرد. برای مثال در این تصویر id=1 از URL بالای صفحه که به http://localhost:3000/products/1 تنظیم شده‌است، دریافت میشود.
بنابراین امکان خواندن اطلاعات پارامترهای مسیریابی، توسط شیء match تزریق شدهی به یک کامپوننت وجود دارد. به همین جهت کامپوننت ProductDetails را ویرایش کرده و المان h1 آن‌را جهت نمایش id محصول به صورت زیر تغییر می‌دهیم که در آن شیء match.params، از props کامپوننت تامین میشود:
برای آزمایش آن مجددا از صفحه‌ی products شروع کرده و بر روی لینک یکی از محصولات، کلیک کنید. در اینجا هرچند id محصول به درستی نمایش داده میشود، اما ... نمایش جزئیات آن به همراه بارگذاری کامل و مجدد صفحه‌ی آن است که از حالت SPA خارج شده‌است. برای رفع این مشکل به کامپوننت products مراجعه کرده و anchorهای تعریف شده را همانطور که در قسمت قبل نیز بررسی کردیم، تبدیل به کامپوننت Link می‌کنیم.
از حالت قبلی:
به حالت جدید:
با این تغییر دیگر در حین نمایش یک کامپوننت، بارگذاری کامل صفحه رخ نمی‌دهد.
پارامترهای اختیاری مسیریابی
به تعریف مسیریابی زیر، دو پارامتر سال و ماه، اضافه شده‌اند:
و برای مثال اگر بر روی لینک posts در منوی راهبری کلیک کنیم، آدرسی مانند http://localhost:3000/posts/2018/06 ایجاد شده و سپس کامپوننت Posts رندر میشود. حال اگر پارامتر ماه را حذف کنیم http://localhost:3000/posts/2018 چه اتفاقی رخ می‌دهد؟ در این حالت برنامه کامپوننت Home را نمایش خواهد داد. علت اینجا است که پارامترهای تعریف شدهی در مسیریابی، به صورت پیش‌فرض اجباری هستند. به همین جهت URL وارد شده، چون با الگوی تعریفی Route فوق بدلیل نداشتن قسمت ماه، انطباق نیافته و تنها مسیریابی / که کامپوننت Home را نمایش می‌دهد، با آن تطابق یافته‌است.
برای رفع این مشکل میتوان با اضافه کردن یک ? به هر پارامتر، پارامترهای تعریف شده را اختیاری کرد:
در regexهای جاوا اسکریپتی زمانیکه یک ? را به یک عبارت باقاعده اضافه می‌کنیم، یعنی آن عبارت اختیاری است.
با این تغییرات اگر مجددا آدرس http://localhost:3000/posts/2018 را درخواست کنیم، کامپوننت Posts بجای کامپوننت Home نمایش داده میشود.
اکنون کامپوننت Posts را به صورت زیر تغییر می‌دهیم تا پارامترهای مسیریابی را نیز درج کند:
پارامتر ({ match }) در اینجا به این معنا است که شیء props ارسالی به آن، توسط Object Destructuring تجزیه شده و خاصیت match آن در اینجا به صورت یک پارامتر در اختیار کامپوننت بدون حالت تابعی قرار گرفته‌است.
پس از ذخیره سازی این تغییرات و بارگذاری مجدد برنامه در مرورگر، اگر آدرس http://localhost:3000/posts/2018/1 را وارد کنیم، خروجی زیر حاصل میشود:
کار با پارامترهای کوئری استرینگ‌های مسیریابی
پارامترهای اختیاری، جزو قابلیت‌هایی هستند که باید تا حد ممکن از بکارگیری آنها اجتناب و آنها را با کوئری استرینگ‌ها تعریف کرد. کوئری استرینگ‌ها با یک ? در انتهای URL شروع می‌شوند و می‌توانند چندین پارامتر را داشته باشند؛ مانند: http://localhost:3000/posts?sortBy=newest&approved=true و یا حتی میتوان آنها را با پارامترهای اختیاری نیز ترکیب کرد مانند: http://localhost:3000/posts/2018/05?sortBy=newest&approved=true
برای استخراج کوئری استرینگ‌ها در برنامه‌های React باید از شیء location استفاده کرد:
در اینجا مقدار خاصیت search، کل قسمت کوئری استرینگ‌ها را به همراه دارد. البته ما قصد پردازش آن‌را به صورت دستی نداریم. به همین جهت از کتابخانه‌ی زیر برای انجام اینکار استفاده خواهیم کرد:
پس از نصب کتابخانه‌ی بسیار معروف query-string، به کامپوننت Posts مراجعه کرده و تغییرات زیر را اعمال می‌کنیم:
- پیشتر ذکر پارامتر ({ match }) را بررسی کردیم. در اینجا خاصیت location نیز به آن اضافه شده‌است تا پس از Object Destructuring شیء props ارسالی به کامپوننت، بتوان به مقدار شیء location نیز دسترسی یافت.
- سپس شیء queryString را از ماژول مرتبط، import می‌کنیم. در ادامه به کمک متد parse آن، میتوان location.search را آنالیز کرد که خروجی آن، یک شیء جاوا اسکریپتی به صورت زیر است:
بنابراین در اینجا هم میتوان توسط Object Destructuring، به این خواص دسترسی یافت:
یک نکته: باید دقت داشت که کتابخانه‌ی query-string، همیشه مقادیر خواص را رشته‌ای بازگشت می‌دهد؛ حتی اگر عدد باشند.
مدیریت مسیرهای نامعتبر درخواستی
فرض کنید کاربری آدرس غیرمعتبر http://localhost:3000/xyz را که هیچ نوع مسیریابی را برای آن تعریف نکرده‌ایم، درخواست می‌کند. در این حالت برنامه کامپوننت home را رندر می‌کند که مرتبط است با تعاریف مسیریابی برنامه در فایل app.js. تنها path تعریف شده‌ای که با این آدرس تطابق پیدا می‌کند، / متناظر با کامپوننت home است.
بجای این رفتار پیش‌فرض، مایل هستیم که کاربر به یک صفحه‌ی سفارشی «پیدا نشد» هدایت شود. به همین جهت ابتدا کامپوننت جدید تابعی بدون حالت src\components\notFound.jsx را با محتوای زیر ایجاد می‌کنیم:
سپس ابتدا به مسیریابی /، ویژگی exact را هم اضافه می‌کنیم تا دیگر بجز ریشه‌ی سایت، به مسیر دیگری پاسخ ندهد:
اکنون اگر مجددا مسیر xyz را درخواست کنیم، فقط کامپوننت NavBar در صفحه ظاهر میشود. برای بهبود این وضعیت و نمایش کامپوننت NotFound، مراحل زیر را طی می‌کنیم:
- ابتدا شیء Redirect را از react-router-dom باید import کنیم.
- همچنین import کامپوننت NotFound نیز باید ذکر شود.
- سپس پیش از مسیریابی کلی /، مسیریابی جدید not-found را که به کامپوننت NotFound اشاره می‌کند، اضافه می‌کنیم.
- اکنون در انتهای Switch تعریف شده (جائی که دیگر هیچ مسیریابی تعریف شده‌ای، با مسیر درخواستی کاربر، تطابق نداشته)، باید کامپوننت Redirect را جهت هدایت به این مسیریابی جدید، تعریف کرد:
پس از این تغییرات، اگر آدرس نامعتبر http://localhost:3000/xyz درخواست شود، بلافاصله به آدرس http://localhost:3000/not-found هدایت می‌شویم.
کاربرد دیگر کامپوننت Redirect، هدایت کاربران از یک آدرس قدیمی، به یک آدرس جدید است که نحوه‌ی تعریف آن به صورت زیر می‌باشد:
با این تنظیم اگر کاربری مسیر http://localhost:3000/messages را درخواست دهد، به صورت خودکار به http://localhost:3000/posts هدایت خواهد شد.
هدایت کاربران به آدرس‌های مختلف با برنامه نویسی
گاهی از اوقات پس از تکمیل فرمی و یا کلیک بر روی دکمه‌ای، می‌خواهیم کاربر را به آدرس خاصی هدایت کنیم. برای مثال در برنامه‌ی جاری می‌خواهیم زمانیکه کاربری صفحه‌ی جزئیات یک محصول را مشاهده و بر روی دکمه‌ی فرضی Save کلیک کرد، دوباره به همان صفحه‌ی لیست محصولات هدایت شود؛ برای این منظور از شیء history استفاده خواهیم کرد:
در اینجا متدها و خواص شیء history را مشاهده می‌کنید. برای نمونه توسط متد push آن میتوان آدرس جدیدی را به تاریخچه‌ی آدرس‌های مرور شدهی توسط کاربر، اضافه کرد و کاربر را با برنامه نویسی، به صفحه‌ی جدیدی هدایت نمود:
یک نکته: اگر به تصویر دقت کنید، متد replace هم در اینجا قابل استفاده است. متد push با افزودن رکوردی به تاریخچه‌ی آدرس‌های مرور شدهی در مرورگر، امکان بازگشت به محل قبلی را با کلیک بر روی دکمه‌ی back مرورگر، فراهم می‌کند؛ اما replace تنها رکورد آدرس جاری را در تاریخچه‌ی مرورگر به روز رسانی می‌کند. یعنی از داشتن تاریخچه محروم خواهیم شد. عمده‌ی کاربرد این متد، در صفحات لاگین است؛ زمانیکه کاربر به سیستم وارد میشود و به صفحه‌ی جدیدی مراجعه می‌کند، با کلیک بر روی دکمه‌ی back، دوباره نمی‌خواهیم او را به صفحه‌ی لاگین هدایت کنیم.
تعریف مسیریابی‌های تو در تو
قصد داریم به صفحه‌ی admin، دو لینک جدید به مطالب و کاربران ادمین را اضافه کنیم، به نحوی که با کلیک بر روی هر کدام، محتوای هر صفحه‌ی متناظر، در همینجا نمایش داده شود (تصویر فوق). به عبارتی در حال حاضر، مسیریابی تعریف شده، جهت مدیریت لینک‌های NavBar بالای صفحه کار می‌کند. اکنون می‌خواهیم مسیریابی دیگری را داخل آن برای پوشش منوی کنار صفحه‌ی ادمین اضافه کنیم. به اینکار، تعریف مسیریابی‌های تو در تو گفته میشود و پیاده سازی آن توسط کامپوننت react-router-dom بسیار ساده‌است و شامل این موارد میشود:
- ابتدا مسیریابی‌های جدید را همینجا داخل کامپوننت src\components\admin\dashboard.jsx تعریف می‌کنیم:
در اینجا محتوای کامپوننت بدون حالت تابعی Dashboard را ملاحظه می‌کنید که از یک کامپوننت منوی SideBar و سپس در ستونی دیگر، از 2 کامپوننت Route تشکیل شده‌است که بر اساس URL رسیده، سبب رندر کامپوننت‌های جدید Users و Posts خواهند شد.
تنها نکته‌ی جدید آن، امکان درج کامپوننت Route در قسمت‌های مختلف برنامه، خارج از app.js می‌باشد و این امکان محدود به app.js نیست. در این حالت اگر مسیر /admin/posts توسط کاربر وارد شد، دقیقا در همان محلی که کامپوننت Route درج شده‌است، کامپوننت متناظر با این مسیر یعنی کامپوننت Posts، رندر میشود.
در ادامه محتوای این کامپوننت‌های جدید را نیز ملاحظه می‌کنید:
محتوای کامپوننت src\components\admin\sidebar.jsx
محتوای کامپوننت src\components\admin\users.jsx
محتوای کامپوننت src\components\admin\posts.jsx
کدهای کامل این قسمت را از اینجا می‌توانید دریافت کنید: sample-15-part-02.zip
دریافت پارامترهای مسیریابی
گاهی از اوقات نیاز به ارسال پارامترهایی به مسیریابی‌های تعریف شده‌است. برای مثال در لیست محصولات تعریف شده، بسته به انتخاب هر کدام، باید id متناظری نیز در URL نهایی ظاهر شود. به این Id، یک Route parameter گفته میشود. برای پیاده سازی این نیازمندی به صورت زیر عمل می‌کنیم:
در فایل app.js، یک مسیریابی جدید را برای نمایش جزئیات یک محصول اضافه می‌کنیم:
import ProductDetails from "./components/productDetails";
// ...
class App extends Component {
render() {
return (
<div>
<NavBar />
<div className="container">
<Switch>
<Route path="/products/:id" component={ProductDetails} />
<Route
path="/products"
render={props => (
<Products param1="123" param2="456" {...props} />
)}
/>
<Route path="/posts/:year/:month" component={Posts} />
<Route path="/admin" component={Dashboard} />
<Route path="/" component={Home} />
</Switch>
</div>
</div>
);
}
} کامپوننت جدید src\components\productDetails.jsx نیز به صورت زیر تعریف شده‌است:
import React, { Component } from "react";
class ProductDetails extends Component {
handleSave = () => {
// Navigate to /products
};
render() {
return (
<div>
<h1>Product Details - </h1>
<button className="btn btn-primary" onClick={this.handleSave}>
</div>
);
}
}
export default ProductDetails; 
در اینجا با گشودن اطلاعات خاصیت match تزریق شدهی به کامپوننت ProductDetails، میتوان اطلاعاتی مانند پارامترهای دریافتی مسیریابی را دقیقا مشاهده کرد. برای مثال در این تصویر id=1 از URL بالای صفحه که به http://localhost:3000/products/1 تنظیم شده‌است، دریافت میشود.
بنابراین امکان خواندن اطلاعات پارامترهای مسیریابی، توسط شیء match تزریق شدهی به یک کامپوننت وجود دارد. به همین جهت کامپوننت ProductDetails را ویرایش کرده و المان h1 آن‌را جهت نمایش id محصول به صورت زیر تغییر می‌دهیم که در آن شیء match.params، از props کامپوننت تامین میشود:
<h1>Product Details - {this.props.match.params.id} </h1> برای آزمایش آن مجددا از صفحه‌ی products شروع کرده و بر روی لینک یکی از محصولات، کلیک کنید. در اینجا هرچند id محصول به درستی نمایش داده میشود، اما ... نمایش جزئیات آن به همراه بارگذاری کامل و مجدد صفحه‌ی آن است که از حالت SPA خارج شده‌است. برای رفع این مشکل به کامپوننت products مراجعه کرده و anchorهای تعریف شده را همانطور که در قسمت قبل نیز بررسی کردیم، تبدیل به کامپوننت Link می‌کنیم.
از حالت قبلی:
{this.state.products.map(product => (
<li key={product.id}>
<a href={`/products/${product.id}`}>{product.name}</a>
</li>
))} import { Link } from "react-router-dom";
// ...
<Link to={`/products/${product.id}`}>{product.name}</Link> پارامترهای اختیاری مسیریابی
به تعریف مسیریابی زیر، دو پارامتر سال و ماه، اضافه شده‌اند:
<Route path="/posts/:year/:month" component={Posts} /> برای رفع این مشکل میتوان با اضافه کردن یک ? به هر پارامتر، پارامترهای تعریف شده را اختیاری کرد:
<Route path="/posts/:year?/:month?" component={Posts} /> با این تغییرات اگر مجددا آدرس http://localhost:3000/posts/2018 را درخواست کنیم، کامپوننت Posts بجای کامپوننت Home نمایش داده میشود.
اکنون کامپوننت Posts را به صورت زیر تغییر می‌دهیم تا پارامترهای مسیریابی را نیز درج کند:
import React from "react";
const Posts = ({ match }) => {
return (
<div>
<h1>Posts</h1>
Year: {match.params.year} , Month: {match.params.month}
</div>
);
};
export default Posts; پس از ذخیره سازی این تغییرات و بارگذاری مجدد برنامه در مرورگر، اگر آدرس http://localhost:3000/posts/2018/1 را وارد کنیم، خروجی زیر حاصل میشود:
کار با پارامترهای کوئری استرینگ‌های مسیریابی
پارامترهای اختیاری، جزو قابلیت‌هایی هستند که باید تا حد ممکن از بکارگیری آنها اجتناب و آنها را با کوئری استرینگ‌ها تعریف کرد. کوئری استرینگ‌ها با یک ? در انتهای URL شروع می‌شوند و می‌توانند چندین پارامتر را داشته باشند؛ مانند: http://localhost:3000/posts?sortBy=newest&approved=true و یا حتی میتوان آنها را با پارامترهای اختیاری نیز ترکیب کرد مانند: http://localhost:3000/posts/2018/05?sortBy=newest&approved=true
برای استخراج کوئری استرینگ‌ها در برنامه‌های React باید از شیء location استفاده کرد:
در اینجا مقدار خاصیت search، کل قسمت کوئری استرینگ‌ها را به همراه دارد. البته ما قصد پردازش آن‌را به صورت دستی نداریم. به همین جهت از کتابخانه‌ی زیر برای انجام اینکار استفاده خواهیم کرد:
> npm i query-string --save
import queryString from "query-string";
const Posts = ({ match, location }) => {
const result = queryString.parse(location.search);
console.log(result);
// ... - سپس شیء queryString را از ماژول مرتبط، import می‌کنیم. در ادامه به کمک متد parse آن، میتوان location.search را آنالیز کرد که خروجی آن، یک شیء جاوا اسکریپتی به صورت زیر است:
{approved: "true", sortBy: "newest"} const { approved, sortBy } = queryString.parse(location.search); یک نکته: باید دقت داشت که کتابخانه‌ی query-string، همیشه مقادیر خواص را رشته‌ای بازگشت می‌دهد؛ حتی اگر عدد باشند.
مدیریت مسیرهای نامعتبر درخواستی
فرض کنید کاربری آدرس غیرمعتبر http://localhost:3000/xyz را که هیچ نوع مسیریابی را برای آن تعریف نکرده‌ایم، درخواست می‌کند. در این حالت برنامه کامپوننت home را رندر می‌کند که مرتبط است با تعاریف مسیریابی برنامه در فایل app.js. تنها path تعریف شده‌ای که با این آدرس تطابق پیدا می‌کند، / متناظر با کامپوننت home است.
بجای این رفتار پیش‌فرض، مایل هستیم که کاربر به یک صفحه‌ی سفارشی «پیدا نشد» هدایت شود. به همین جهت ابتدا کامپوننت جدید تابعی بدون حالت src\components\notFound.jsx را با محتوای زیر ایجاد می‌کنیم:
import React from "react";
const NotFound = () => {
return <h1>Not Found</h1>;
};
export default NotFound; <Route path="/" exact component={Home} /> - ابتدا شیء Redirect را از react-router-dom باید import کنیم.
- همچنین import کامپوننت NotFound نیز باید ذکر شود.
- سپس پیش از مسیریابی کلی /، مسیریابی جدید not-found را که به کامپوننت NotFound اشاره می‌کند، اضافه می‌کنیم.
- اکنون در انتهای Switch تعریف شده (جائی که دیگر هیچ مسیریابی تعریف شده‌ای، با مسیر درخواستی کاربر، تطابق نداشته)، باید کامپوننت Redirect را جهت هدایت به این مسیریابی جدید، تعریف کرد:
import { Redirect, Route, Switch } from "react-router-dom";
//...
import NotFound from "./components/notFound";
//...
class App extends Component {
render() {
return (
<div>
<NavBar />
<div className="container">
<Switch>
//...
<Route path="/not-found" component={NotFound} />
<Route path="/" exact component={Home} />
<Redirect to="/not-found" />
</Switch>
</div>
</div>
);
}
} کاربرد دیگر کامپوننت Redirect، هدایت کاربران از یک آدرس قدیمی، به یک آدرس جدید است که نحوه‌ی تعریف آن به صورت زیر می‌باشد:
<Redirect from="/messages" to="/posts" />
هدایت کاربران به آدرس‌های مختلف با برنامه نویسی
گاهی از اوقات پس از تکمیل فرمی و یا کلیک بر روی دکمه‌ای، می‌خواهیم کاربر را به آدرس خاصی هدایت کنیم. برای مثال در برنامه‌ی جاری می‌خواهیم زمانیکه کاربری صفحه‌ی جزئیات یک محصول را مشاهده و بر روی دکمه‌ی فرضی Save کلیک کرد، دوباره به همان صفحه‌ی لیست محصولات هدایت شود؛ برای این منظور از شیء history استفاده خواهیم کرد:
در اینجا متدها و خواص شیء history را مشاهده می‌کنید. برای نمونه توسط متد push آن میتوان آدرس جدیدی را به تاریخچه‌ی آدرس‌های مرور شدهی توسط کاربر، اضافه کرد و کاربر را با برنامه نویسی، به صفحه‌ی جدیدی هدایت نمود:
class ProductDetails extends Component {
handleSave = () => {
// Navigate to /products
this.props.history.push("/products");
}; یک نکته: اگر به تصویر دقت کنید، متد replace هم در اینجا قابل استفاده است. متد push با افزودن رکوردی به تاریخچه‌ی آدرس‌های مرور شدهی در مرورگر، امکان بازگشت به محل قبلی را با کلیک بر روی دکمه‌ی back مرورگر، فراهم می‌کند؛ اما replace تنها رکورد آدرس جاری را در تاریخچه‌ی مرورگر به روز رسانی می‌کند. یعنی از داشتن تاریخچه محروم خواهیم شد. عمده‌ی کاربرد این متد، در صفحات لاگین است؛ زمانیکه کاربر به سیستم وارد میشود و به صفحه‌ی جدیدی مراجعه می‌کند، با کلیک بر روی دکمه‌ی back، دوباره نمی‌خواهیم او را به صفحه‌ی لاگین هدایت کنیم.
تعریف مسیریابی‌های تو در تو
قصد داریم به صفحه‌ی admin، دو لینک جدید به مطالب و کاربران ادمین را اضافه کنیم، به نحوی که با کلیک بر روی هر کدام، محتوای هر صفحه‌ی متناظر، در همینجا نمایش داده شود (تصویر فوق). به عبارتی در حال حاضر، مسیریابی تعریف شده، جهت مدیریت لینک‌های NavBar بالای صفحه کار می‌کند. اکنون می‌خواهیم مسیریابی دیگری را داخل آن برای پوشش منوی کنار صفحه‌ی ادمین اضافه کنیم. به اینکار، تعریف مسیریابی‌های تو در تو گفته میشود و پیاده سازی آن توسط کامپوننت react-router-dom بسیار ساده‌است و شامل این موارد میشود:
- ابتدا مسیریابی‌های جدید را همینجا داخل کامپوننت src\components\admin\dashboard.jsx تعریف می‌کنیم:
const Dashboard = ({ match }) => {
return (
<div>
<h1>Admin Dashboard</h1>
<div className="row">
<div className="col-3">
<SideBar />
</div>
<div className="col">
<Route path="/admin/users" component={Users} />
<Route path="/admin/posts" component={Posts} />
</div>
</div>
</div>
);
}; تنها نکته‌ی جدید آن، امکان درج کامپوننت Route در قسمت‌های مختلف برنامه، خارج از app.js می‌باشد و این امکان محدود به app.js نیست. در این حالت اگر مسیر /admin/posts توسط کاربر وارد شد، دقیقا در همان محلی که کامپوننت Route درج شده‌است، کامپوننت متناظر با این مسیر یعنی کامپوننت Posts، رندر میشود.
در ادامه محتوای این کامپوننت‌های جدید را نیز ملاحظه می‌کنید:
محتوای کامپوننت src\components\admin\sidebar.jsx
import React from "react";
import { Link } from "react-router-dom";
const SideBar = () => {
return (
<ul className="list-group">
<li className="list-group-item">
<Link to="/admin/posts">Posts</Link>
</li>
<li className="list-group-item">
<Link to="/admin/users">Users</Link>
</li>
</ul>
);
};
export default SideBar; محتوای کامپوننت src\components\admin\users.jsx
import React from "react";
const Users = () => {
return <h1>Admin Users</h1>;
};
export default Users; محتوای کامپوننت src\components\admin\posts.jsx
import React from "react";
const Posts = () => {
return (
<div>
<h1>Admin Posts</h1>
</div>
);
};
export default Posts; کدهای کامل این قسمت را از اینجا می‌توانید دریافت کنید: sample-15-part-02.zip