Improve the collection experience – Change the collection components

Note: this article is for TP5.0, due to different versions of TP compatibility problems, the following content is for reference only.

Programming is a pain in the ass, but using frameworks is meant to make development faster and more enjoyable. But understanding a framework comes with costs and risks. Many people look for frameworks based on online recommendations rather than source architecture analysis, let alone github testing coverage and code quality identification. Therefore, under normal circumstances, the way to choose the framework is mostly TP, CI, etc., which is to let themselves into the pit, is to find out. Once it happens, we can only fix it. Because the cost of starting over is too high. This series of articles is a record of the author, as a Laravel user, taking over the TP project and constantly being abused and tortured to improve the experience.

No comparison, no harm. If you are a Laravel user, you will be frustrated by the tp development experience. In fact, even if you are a Symfony user, cake user, yII user, it feels the same. Because the development experience of these frameworks is better than tp. Cake has never taken off in China. Most of those who choose CI are beginners and think it is simpler than TP.

Of course, the so-called 10 years of sharpening a sword TP5 many places now seem to be copying or imitating Laravel, some are copy and paste, but with the early version, for now, simply not enough. For example, collection looks like this. Some are rewrites or imitations, but more maddening than others. Like the Model. There are quite a few functions in this class that are more than a hundred lines, and the nesting of 5 to 8 layers of If is also extremely large.

Now programmers are Clean Code, Don’t Write Next Loop. Why is that? Because life is short, speed of development is the most important thing.

Tp’s collection should only have the functionality of Laravel4 or 5. So, to optimize the development experience, replace it. Why change? Because I had to. You don’t make the project. You’re just taking on someone else’s project. Change the frame, everything has to be rewritten. But you don’t want to be abused by TP. Maybe, the leader wants you to move slowly to Laravel. What can you do? The best way to do this is to replace it locally, eating away at what’s causing you pain.

How do I change it? First, you can install tightenco/ Collect, a Collection package stripped from Laravel by a third party. Of course, what’s better now is that the Laravel Illuminate/Collections package itself can be installed independently. So, you can also install the official package. The difference between the two packs, unofficially, also sent dd. You never know how good DD is.

Of course, after the installation is complete, it is not directly usable. Tp is the same as Laravel’s Collection-related helper functions.

So, you need to test to see which object the collect function ends up creating. If it is still TP, there are several ways.

1, directly modify tp assistant function source code. Comment out functions with the same name as Laravel Collection.

2. For more advanced users, you can write your own set of helper functions.

However, the problem is that the Model used for database query results is still a Collection of TP. Tp is the Collection class used in the configuration. As a result, the two classes have the same name, and it is useless to change the configuration unless you change the type. However, it can still be modified. To do this, you create a class BaseModel that inherits tp’s Model, and then copy the source code for the toCollection method in TP’s Model to call Laravel’s Collection. So, next, the entity’s Model all inherits the BaseModel you just implemented. So you can use Laravel collections for grouping, sorting, paging and so on. The code is as follows:

.use Tightenco\Collect\Support\Collection as ModelCollection; ./**
 * Class BaseModel
 *
 * @package app\api\mpmodel
 */
class BaseModel extends Model
{.../** * Convert the current model dataset to dataset object *@access public
     * @paramArray | \ Tightenco/Collect/Support/Collection $* Collection data set@return \Tightenco\Collect\Support\Collection
     */
    public function toCollection($collection)
    {
        if ($this->resultSetType) {
            if ('collection'= =$this->resultSetType) {
                $collection = new ModelCollection($collection);
            } elseif (false! == strpos($this->resultSetType, '\ \')) {
                $class      = $this->resultSetType;
                $collection = new $class($collection); }}return $collection; }...Copy the code

At this point, the Collection Collection component has been successfully replaced. All that’s left is for the model to inherit from the model you just implemented. The second thing is to replace all the loops that you can now replace with sets. You’ll feel light and refreshed. Indeed, things will get better and better, and soon you’ll be using the number one Laravel framework in the world. Come on!