ساخت فروم با لاراول و TDD

بیایید با بررسی حداقل شرایط لازم برای یک فروم شروع کنیم.اگر به آن فکر کنید ، ما نمی توانیم بدون کاربران ، موضوعات و پاسخها یک فروم ایجاد کنیم.

اکنون که داده seed خود را در اختیار داریم ، می توانیم سراغ یک ویژگی کوچک برویم: "یک کاربر باید بتواند موضوعات را بخواند." همینقدر ساده! ما با یک تست اولیه شروع می کنیم ، و سپس آن را گسترش میدهیم..

اکنون که یک ویژگی اصلی برای خواندن موضوعات انجمن اضافه کرده ایم ، می توانیم در ادامه مشاهده همه پاسخ های مرتبط با هر موضوع را شروع کنیم. مانند گذشته ، ما برای نتیجه مطلوب خود با یک تست شروع خواهیم کرد.

ما عملکردهای لازم را برای ارائه یک متن با تمام پاسخ های مربوطه اعمال کرده ایم ، اما هنوز به کاربر اجازه نداده ایم که یک پاسخ را تایپ کند و آن را به سرور ارسال کند. بیایید از همین حالا شروع کنیم.

اکنون که ما end-point را برای اضافه کردن پاسخ جدید تست کرده ایم ، تنها مرحله باقی مانده ایجاد HTML برای فرم است. در این فرآیند ، ما همچنین مطمئن خواهیم شدکه فقط کاربران لاگین کرده قادر به دیدن آن هستند.

تا الان کاربر می تواند موضوعات را بخواند و پاسخ دهد ، اما آنها هنوز توانایی انتشار موضوعات خود را ندارند. بیایید این قسمت را بررسی کنیم.

I'm a big fan of making the process of writing tests as natural as humanly possible. The harder it is to construct a test, the more likely it is that you simply...won't. With that in mind, let's extract a few helpers and snippets to assist us.

اکنون که تست های endpoint ما تمام شده اند ، می توانیم فرم HTML را برای انتشار موضوع جدید بسازیم. با این حال ، در این فرایند در برخی موارد استثناء دچار مشکل خواهیم شد. خوشبختانه ،Adam Wathan راه حل مفیدی دارد که ما می توانیم آن را پیاده سازی کنیم.

در حال حاضر ، همه موضوعات به صورت "global" است . در حالت ایده آل ، ما باید هر موضوع را به یک کانال اختصاص دهیم. به این ترتیب ، برای یک دولوپر فروم ، ما می توانیم به راحتی موضوعات را توسط PHP یا JavaScript یا سرور فیلتر کنیم.

ما هنوز هیچ منطقی برای اعتبار سنجی برای فروم خود ننوشتیم. این بدان معنی است که یک کاربر می تواند با انواع داده های نامعتبر یک درخواست را ارسال کند ، و ما آن را در بانک اطلاعاتی قراردهیم. بیایید این مسئله را در این قسمت حل کنیم.

اکنون که همه موضوعات را با یک کانال مرتبط کرده ایم ، اکنون می توانیم اپدیت های ضروری UI را انجام دهیم تا کاربران بتوانند موضوعات را توسط کانال مورد نظر خود فیلتر کنند.

در این قسمت ، ما باید در صفحه "ایجاد موضوع" کمی کار انجام دهیم. ما ابتدا لینکی به نوار پیمایش یا navigation bar اضافه می کنیم و سپس به سراغ تغییر فرم خود ، می رویم. به طور خاص ، ما باید بازخورد خطای اعتبارسنجی را ارائه دهیم ، و اطمینان حاصل کنیم که در صورت ایجاد خطای اعتبارسنجی ، متنی که کاربر در قسمتهای مختلف فرم وارد می کند ، یادآوری می شود..

در حال حاضر ، ما دو کوئری مختلف SQL برای واکشی کلیه کانالها به طور مستقیم در لایه view خود داریم. بیایید در این آموزش آن را با استخراج یک view composer اختصاصی رفع کنیم.

اگر هر کاربر بتواند لینکی داشته باشد که فقط موضوعاتی را که شخصاً ایجاد کرده است را ببینید خیلی خوب است. و حتی فراتر از آن ، چرا نمی توان امکان مشاهده موضوعات کاربر را فراهم کرد؟ بیایید در این آموزش این را بررسی کنیم.

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

برای اطلاعات متنوع ، مانند زمان انتشار موضوع ، تعداد پاسخ ها و موارد دیگر ، باید یک sidebar به هر صفحه موضوع اضافه کنیم. علاوه بر این ، باید pagination را به برنامه خود اضافه کنیم. چه اتفاقی می افتد وقتی که یک موضوع بیش از صد پاسخ داشته باشد؟ بیایید مطمئن شویم که پیوندهای pagination مناسب را به کار می بریم.

اگر کاربران توانایی فیلتر کردن همه موضوعات با محبوبیت بیشتر را داشته باشند خیلی خوب است. به این ترتیب ، فعال ترین موضوعات همیشه بالا قرار میگیرند. بیایید یک تست بنویسیم و سپس این feature را اجرا کنیم.

این امر مفید خواهد بود اگر کاربران معتبر (authenticated ) بتوانند توانایی پاسخگویی به موضوعات مورد علاقه خودشان را داشته باشند. بیایید پیاده سازی این قابلیت ها را با استفاده از روابط polymorphic شروع کنیم.

اکنون که فرآیند کامل favoriting a reply را تست کرده ایم ، می توانیم به سمت ایجاد فرمی برای پردازش این اکشن برای یوزر برویم. در این فرآیند، در مورد N+1 problem بحث خواهیم کرد.

میخواهیم مسئله N + 1 را مرور کنیم ، زیرا مربوط به Eloquent است. برای این کار ، Laravel Debugbar را نصب می کنیم تا بتوانیم کوئری های دقیق SQL را که برای هر بار صفحه اجرا می شود ، تجزیه و تحلیل کنیم. همانطور که یاد خواهید گرفت ، چندین گام ساده وجود دارد که می توانیم برای کاهش تعداد کوئری های خود توسط ده ها نفر استفاده کنیم.

In this episode, we'll continue optimizing our SQL queries. Specifically, we'll review global Eloquent scopes and the useful $with property to automatically eager load any necessary relationships.

It would be useful if every user in our forum had an associated profile page. That way, we can review more information about them, including all threads that they've personally created.

One simple ability that we haven't yet implemented is the option to delete threads. If "John Doe" creates a thread and later changes his mind, let's allow him to delete it entirely.

We must be careful that we don't inadvertently give any registered forum user the ability to delete all threads. Let's create a policy class to ensure that this can't happen.

In this episode, we'll use TDD to drive out an activity feed. That way, we can, for example, track when a user creates a new forum thread, or posts a reply. As always, we'll begin with the most basic possible implementation. Once we get to green, we can then move on to the refactoring stage to clean things up drastically.

Now that we've written the necessary code to record all relevant activity, in this episode, we can render it onto the user's profile page, and group all relevant records according to their date.

At the moment, we have a long, fluent Eloquent query in our controller. Instead, let's use TDD to extract it into the Activity model.

I think we have a bug in our activity feed. What happens if we delete a thread? Will that cascade and delete all relevant activity in the process? And, if not, what happens when we try to view the user's profile page? Hmm, let's write a regression test to find out.

In this episode, we'll implement an elegant flash messaging system, using Vue. That way, when a user performs an important action, we can flash a quick message to indicate the outcome.

At the moment, a user's activity feed will exclusively display a timeline of their own threads and replies. Let's extend that in this episode to include any replies that they've favorited.

We're still missing a very basic piece of functionality. Any authorized user should be able to delete a reply. Let's implement that in this episode.

We're starting to realize that each individual forum reply should have a decent amount of behavior associated with it. With that in mind, in this episode we'll create a dedicated Vue component for a reply, and then implement the necessary functionality to quickly edit the body of a reply without requiring a page refresh.

Now that each reply is wrapped within a dedicated Vue instance, we can easily swap out the traditional form for deleting the reply with a snappier AJAX version that doesn't require a page refresh.

We have one last piece of the puzzle, when it comes to our Reply component. The favoriting functionality still consists of a traditional form. Let's turn that into a dedicated Favorite component to clean things up.

I think we've introduced a couple of bugs related to adding and removing activity. Let's work through them in this episode and patch things up, before moving on to a new feature.

In this episode, we'll do a decent amount of refactoring to push toward a more data-centric approach, when it comes to our Vue components. As part of this refactor, we'll need to figure out how to rewrite inline-templates that use Blade into JavaScript.

Now that we're thinking in terms of Vue collections, we can easily turn the form for publishing a new reply into its own component. This way, when the user submits the form, we can simply perform an AJAX call to persist the data, and then push to the "replies" collection - which will, in response, automatically trigger a re-render.

Since we're now rendering all replies with JavaScript, we can no longer depend upon rendering pagination links on the server-side. To compensate, let's create a dedicated paginator Vue component to handle all the necessary logic behavior.

I've learned from running the Laracasts forum that users often want to filter all threads according to those that have not yet received replies. Let's add that very functionality in this episode.

It would be useful if users could subscribe to any number of threads in our forum. That way, each time a reply is left, the user will immediately be notified. Let's get started implementing this very functionality.