Detailed explanation of developing user dynamic module in Laravel

*文
Release: 2023-03-19 08:46:01
Original
1460 people have browsed it

This article mainly introduces to you the relevant information about the development of user dynamic modules based on Laravel. The article introduces it in great detail through sample code. It has certain reference learning value for everyone's study or work. Friends who need it can follow it below. Come and learn with me. I hope to be helpful.

Preface

I believe everyone knows that almost all community applications have a user dynamics section, which users can obtain through friend dynamics More interesting content, thereby increasing community activity and user stickiness. Its implementation is relatively more complicated than ordinary content publishing, mainly reflected in the diversity of content.

In order to solve this problem, we have to abstract these different types of content, extract commonalities, and use the same structure to process them, which will make development much simpler.

Conceptual abstraction

User dynamics, as the name suggests, the generation of dynamics is the historical record of a series of events, so first focus on the "event" Noun, what attributes does it have:

  • Trigger, almost all events based on the community are triggered by users

  • Event subject, event The main information, such as "article" in "xxx published an article".

  • Event attributes, different event subjects require different additional information, such as event type.

  • Occurrence time records the time when the event occurs. Of course, our database usually records the time when all data is generated.

We abstract user dynamics into a structure with only 4 basic attributes, which is easier to implement:

- description    事件描述
- causer_id 或者 user_id 事件触发者
- subject_id    主体 ID
- subject_type   主体类型
- properties    事件附加属性
- created_at    事件产生时间
Copy after login

The main part is the morph relation in Laravel, more state correlation.

How to display

Our dynamic display needs usually include the following:

  • I The dynamics of friends

  • The dynamics of a certain person, usually the personal center

  • all the dynamics, such as all the dynamics on the Laravel China homepage

  • Dynamic search, relatively rare

I am currently developing a new version of EasyWeChat website, which also has user dynamics, for example:

xxx 发布了讨论 《请问大家怎么使用 xxx》
xxx 评论了 xxx 的话题 《请问大家怎么使用 xxx》
xxx 回复了 xxx 的评论 “我是按照文档上 ...”
xxx 购买了 《微信开发:自定义菜单的使用》
xxx 关注了 xxx
...
Copy after login

You will It is found that basically every dynamic is written differently, so we also need to record an "event type", such as "follow", "publish", "reply", and "purchase".

Then when we use blade or other template engines, we can switch... case writing to apply different templates to render these styles. For example, in blade, my usage is:

@switch($activity->properties['event'] ?? '')
 @case('discussion.created')
  ...
  @break
 @case('comment.created')
  ...
  @break
@endswitch
Copy after login

Code Implementation

We have discussed the design of data storage and display before, and then how to implement it. If you are more diligent, you can implement it natively. After all, the above The implementation method has been clearly described, just write some code to implement it. What I would recommend today is to use spatie/laravel-activitylog to implement it:

Installation has always been very simple, right:

$ composer install spatie/laravel-activitylog -vvv
Copy after login

Recording dynamics

activity()->log('Look, I logged something');
Copy after login

Of course this kind of record is meaningless and contains almost no useful information, so our usual usage should be like this:

activity()
 ->performedOn($anEloquentModel)
 ->causedBy($user)
 ->withProperties(['customProperty' => 'customValue'])
 ->log('Look, I logged something');
 
$lastLoggedActivity = Activity::all()->last();

$lastLoggedActivity->subject; //returns an instance of an eloquent model
$lastLoggedActivity->causer; //returns an instance of your user model
$lastLoggedActivity->getExtraProperty('customProperty'); //returns 'customValue'
$lastLoggedActivity->description; //returns 'Look, I logged something'
Copy after login

Method Introduction:

  • performedOn($model) Set the event subject, which is the Eloquent Model instance

  • causedBy($user) Set the event trigger, User instance

  • withProperties($properties) The event properties in our concept above

  • withProperty($key, $value) Single usage of event properties

  • log($description) Event Description

For example, we want to record an update when a user posts a discussion:

$discussion = App\Discussion::create([...]);
activity()->on($discussion)
->withProperty('event', 'discussion.created')
->log('发表了话题');
Copy after login

Or when a user registers, I want to record an update:

activity()->on($user)
->withProperty('event', 'user.created')
->log('加入 EasyWeChat');
Copy after login

You will find that I have not set a trigger, because if you do not set a trigger for this module, it defaults to the currently logged in user.

Display dynamics

Display dynamics is to take them out from the database according to conditions. Here we use the model class provided by the package: Spatie\Activitylog\Models\ Activity

use Spatie\Activitylog\Models\Activity;

// 全部动态
$activities = Activity::all();
// 用户 ID 为 2 的动态 
$activities = Activity::causedBy(User::find(2))->paginate(15);
// 以文章 ID 为 13 为主体的动态
$activities = Activity::forSubject(Post::find(13))->paginate(15);
Copy after login

Then just traverse the display.

Some experience and skills

Set up a special dynamic observer class to record dynamics

$ ./artisan make:listener UserActivitySubscriber
Copy after login

The code is as follows:

<?php 
namespace App\Listeners;
class UserActivitySubscriber
{
 protected $lisen = [
  &#39;eloquent.created: App\User&#39; => &#39;onUserCreated&#39;,
  &#39;eloquent.created: App\Discussion&#39; => &#39;onDiscussionCreated&#39;,
 ];

 public function subscribe($events)
 {
  foreach ($this->lisen as $event => $listener) {
   $events->lisen($event, __CLASS__.&#39;@&#39;.$listener);
  }
 }

 public function onUserCreated($user)
 {
  activity()->on($user)
   ->withProperty(&#39;event&#39;, &#39;user.created&#39;)
   ->log(&#39;加入 EasyWeChat&#39;);
 }

 public function onDiscussionCreated($discussion)
 {
  activity()->on($discussion)
    ->withProperty(&#39;event&#39;, &#39;discussion.created&#39;)->log(&#39;发表了话题&#39;);
 }
}
Copy after login

Then we register this subscription class:

Register this subscription class in $subscribe in App\Providers\EventServiceProvider:

/**
 * @var array
 */
protected $subscribe = [
 \App\Listeners\UserActivitySubscriber::class,
];
Copy after login

Above we used the Eloquent model event to To monitor changes in the model, when various model events are created, we call the corresponding methods to record the dynamics, so it is very convenient to implement.

Record key information in event attributes

When you see the dynamic record above, you may ask, only the ID is stored. This kind of polymorphic association will be very stressful when querying. For example, we want to display the dynamic as:

安Xiaochao published an article "Using Custom Menu"

If we only store the id and type of the article, we also need to query the article table once to get the title for display. Such a dynamic If it is a list, there may be dozens of SQLs. This is indeed the case. My solution is as follows:

In fact, our user dynamics do not require 100% accuracy. Therefore, if I record Does saving the title of the article eliminate the need to look up the table again? In fact, the key information we need to display in the dynamic list, such as the title, is stored together with withProperties, so that a single SQL solves the dynamic list problem.

This approach also has disadvantages. For example, when the title of the article is changed, it will be out of sync. Of course, you can also change this attribute when the article is modified, but I personally think it is not necessary. After all, the dynamic is to record the situation at that time, and there is no problem if the title is changed later.

OK, the development of the user dynamic module will be shared here. If you have a more advanced implementation, please feel free to communicate.

Regarding the implementation of the friend dynamic part, it depends on the size of your application and the storage of friend relationships. You can just brainstorm ideas. Most of them check the friend relationship first and then check the updates. Related queries are also Okay, do it yourself.

Related recommendations:

Detailed explanation of how Laravel optimizes Model queries through preloading

Detailed explanation of modifying the root address of url() in Laravel

Detailed explanation of how Laravel implements scheduled tasks

The above is the detailed content of Detailed explanation of developing user dynamic module in Laravel. For more information, please follow other related articles on the PHP Chinese website!

Related labels:
source:php.cn
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template
About us Disclaimer Sitemap
php.cn:Public welfare online PHP training,Help PHP learners grow quickly!