? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

Baru-baru ini menyerahkan idea kepada rangka kerja Laravel - tambah pengesanan kaedah maklumat penomboran tersuai dalam PaginatedResourceResponse supaya ia boleh dikeluarkan apabila menggunakan Resource kelas Apabila melihat maklumat, adalah sangat mudah untuk menyesuaikan maklumat paging.

Mengapa anda memerlukannya

Pada dasarnya saya membangunkan API. Pada hari-hari awal, saya selalu kembali secara langsung, tetapi kaedah ini kadangkala menyebabkan beberapa masalah dan menyusahkan untuk diselenggara Selain itu, selalunya perlu untuk menambah medan tersuai dan menyediakan data yang berbeza untuk tujuan yang berbeza yang saya gunakan Resource tentukan data yang dikembalikan. [Disyorkan: tutorial video laravel]

Menggunakan Resource sangat mudah dan boleh menjelaskan logiknya. Tetapi ia mempunyai kelemahan, iaitu, terdapat terlalu banyak maklumat penomboran. Untuk projek API, dalam kebanyakan kes, banyak medan dalam maklumat paging output lalai tidak diperlukan, dan kerana ia sering disambungkan kepada beberapa projek lama, format data lama perlu digunakan atau dibuat serasi Medan maklumat paging adalah agak berbeza, tidak ada cara untuk menggunakan maklumat paging yang dikembalikan secara lalai.

Saya tidak tahu bagaimana semua orang mengendalikan maklumat paging dalam situasi yang sama, tetapi sebelum itu, untuk mencapai matlamat, saya biasanya mempunyai dua kaedah Satu ialah menyesuaikan Response, di mana Maklumat data adalah ditakrifkan semula, dan yang kedua adalah untuk menyesuaikan semua Resource kelas yang berkaitan.

Saya tidak tahu banyak tentang lapisan bawah Laravel, dan saya tidak mahir dalam pembangunan rangka kerja abstrak, tetapi selepas melalui ini, saya mendapati bahawa perkara boleh menjadi lebih mudah Seperti yang saya jelaskan dalam PR, jika anda boleh Apabila membina maklumat paging dalam src/Illuminate/Http/Resources/Json/PaginatedResourceResponse.php, anda boleh menggunakan maklumat paging komponen yang sepadan dengan kelas Resource Kemudian anda tidak perlu menghabiskan banyak masa untuk menyesuaikan banyak kelas. Jadi saya menyerahkan idea ini kepada rangka kerja Laravel. Komit ini tidak diterima secara langsung pada mulanya, tetapi telah digabungkan selepas pelarasan Taylor dan dikeluarkan dalam v8.73.2.

Ini adalah kali pertama saya menyumbang kod kepada Laravel, dan ini juga kali pertama saya menyerahkan permintaan gabungan kepada pangkalan kod yang begitu besar Walaupun ia tidak diterima pakai secara langsung, hasilnya menarik cukuplah.

Contoh Penggunaan

Nah, izinkan saya memberikan contoh mudah tentang cara menggunakannya.

Output lalai

{??
????"data":?[],
????"links":?{
????????"first":?"http://cooman.cootab-v4.test/api/favicons?page=1",
????????"last":?"http://cooman.cootab-v4.test/api/favicons?page=1",
????????"prev":?null,
????????"next":?null
????},
????"meta":?{
????????"current_page":?1,
????????"from":?1,
????????"last_page":?1,
????????"links":?[
????????????{
????????????????"url":?null,
????????????????"label":?"??上一頁",
????????????????"active":?false
????????????},
????????????{
????????????????"url":?"http://cooman.cootab-v4.test/api/favicons?page=1",
????????????????"label":?"1",
????????????????"active":?true
????????????},
????????????{
????????????????"url":?null,
????????????????"label":?"下一頁??",
????????????????"active":?false
????????????}
????????],
????????"path":?"http://cooman.cootab-v4.test/api/favicons",
????????"per_page":?15,
????????"to":?5,
????????"total":?5
????}}

Ini ialah output maklumat paging oleh Laravel secara lalai. Sudah tentu, ini sudah cukup untuk menghadapi banyak senario . Tetapi kadang-kadang kita mendapat masalah kerananya. Kami memerlukan sedikit fleksibiliti.

Apabila menggunakan kelas ResourceCollection

Mari kita lihat logik asas dahulu!

Apabila ResourceCollection dikembalikan daripada pengawal, kaedah toResponsenya akhirnya akan dipanggil sebagai tindak balas. Kemudian anda boleh terus mencari kaedah ini dan lihat:

???/**
?????*?Create?an?HTTP?response?that?represents?the?object.
?????*
?????*?@param??\Illuminate\Http\Request??$request
?????*?@return?\Illuminate\Http\JsonResponse
?????*/
????public?function?toResponse($request)
????{
????????if?($this->resource?instanceof?AbstractPaginator?||?$this->resource?instanceof?AbstractCursorPaginator)?{
????????????return?$this->preparePaginatedResponse($request);
????????}

????????return?parent::toResponse($request);
????}

Lihat, jika sumber semasa ialah objek paging, ia akan mengalihkan tugas untuk memproses respons paging. Pandangan seterusnya:

????/**
?????*?Create?a?paginate-aware?HTTP?response.
?????*
?????*?@param??\Illuminate\Http\Request??$request
?????*?@return?\Illuminate\Http\JsonResponse
?????*/
????protected?function?preparePaginatedResponse($request)
????{
????????if?($this->preserveAllQueryParameters)?{
????????????$this->resource->appends($request->query());
????????}?elseif?(!?is_null($this->queryParameters))?{
????????????$this->resource->appends($this->queryParameters);
????????}

????????return?(new?PaginatedResourceResponse($this))->toResponse($request);
????}

Oh, ia telah dipindahkan ke PaginatedResourceResponse sekali lagi. Ini adalah kelas yang akhirnya perlu kami ubah suai Memandangkan kandungan toResponse terlalu panjang, saya tidak akan menyiarkannya Di sini, ia adalah Di sini kita mula membina data respons Sudah tentu, maklumat paging juga diproses di sini, tetapi ia mempunyai kaedah bebas. Kaedahnya ialah paginationInformation, iaitu logik sebelum menyerahkan PR:

/**
?????*?Add?the?pagination?information?to?the?response.
?????*
?????*?@param??\Illuminate\Http\Request??$request
?????*?@return?array
?????*/
????protected?function?paginationInformation($request)
????{
????????$paginated?=?$this->resource->resource->toArray();

????????return?[
????????????'links'?=>?$this->paginationLinks($paginated),
????????????'meta'?=>?$this->meta($paginated),
????????];
????}

Jika anda berhati-hati, anda sepatutnya dapat berfikir bahawa $this->resource di sini sebenarnya adalah contoh di atas ResourceCollection. Maka resource ialah data senarai kami, yang merupakan contoh maklumat halaman. Oleh itu, mengapa kami tidak boleh memproses maklumat halaman dalam ResourceCollection? Sudah tentu, tetapi kami perlu menambah sesuatu, dan itulah idea yang saya serahkan.

Selepas menggabungkan PR, logiknya adalah seperti berikut:

/**
?????*?Add?the?pagination?information?to?the?response.
?????*
?????*?@param??\Illuminate\Http\Request??$request
?????*?@return?array
?????*/
????protected?function?paginationInformation($request)
????{
????????$paginated?=?$this->resource->resource->toArray();

????????$default?=?[
????????????'links'?=>?$this->paginationLinks($paginated),
????????????'meta'?=>?$this->meta($paginated),
????????];

????????if?(method_exists($this->resource,?'paginationInformation'))?{
????????????return?$this->resource->paginationInformation($request,?$paginated,?$default);
????????}

????????return?$default;
????}

Kaedah pemprosesan yang sangat mudah Jika terdapat kaedah pembinaan maklumat paging tersuai dalam kelas sumber yang sepadan, gunakannya Saya sendiri, buat masa ini, ini sememangnya idea yang baik.

Pada ketika ini, cara untuk menyesuaikan maklumat halaman harus jelas. Iaitu untuk menambah kaedah ResourceCollection pada kelas paginationInformation anda yang sepadan, contohnya:

public?function?paginationInformation($request,?$paginated,?$default):?array
????{
????????return?[
????????????'page'?=>?$paginated['current_page'],
????????????'per_page'?=>?$paginated['per_page'],
????????????'total'?=>?$paginated['total'],
????????????'total_page'?=>?$paginated['last_page'],
????????];
????}

這是自定義后的數(shù)據(jù)輸出情況：

{
????"data":?[],
????"page":?1,
????"per_page":?15,
????"total":?5,
????"total_page":?1}

結(jié)果如我所愿。

使用 Resource 類時

我通常只喜歡定義一個 Resource 類來應對單個對象和列表的情況，這里主要關(guān)注如何處理列表數(shù)據(jù)的分頁自定義。

在控制器中，我一般都是這樣使用：

public?function?Index(){
????//?....
????return??SomeResource::collection($paginatedData);}

再來看看 collection 方法里做了什么：

???/**
?????*?Create?a?new?anonymous?resource?collection.
?????*
?????*?@param??mixed??$resource
?????*?@return?\Illuminate\Http\Resources\Json\AnonymousResourceCollection
?????*/
????public?static?function?collection($resource)
????{
????????return?tap(new?AnonymousResourceCollection($resource,?static::class),?function?($collection)?{
????????????if?(property_exists(static::class,?'preserveKeys'))?{
????????????????$collection->preserveKeys?=?(new?static([]))->preserveKeys?===?true;
????????????}
????????});
????}

原來它把數(shù)據(jù)轉(zhuǎn)給了 ResourceCollection，那么只需要將這個 ?AnonymousResourceCollection 做個自定義不就可以了。

總結(jié)

這是一個很小優(yōu)化，但是很有用。

在此之前，如果想要隨著 Resource 返回自定義分頁信息，會比較麻煩，需要自定義很多東西，這樣的方式，對老用戶而言小菜一碟，但是對新手就可能是件棘手的問題。那么自此之后，無論是老用戶還是新手這件事將變得易如反掌。只需要在對應的 ResourceCollection 類中添加 paginationInformation 方法，類似下面這樣：

public?function?paginationInformation($request,?$paginated,?$default):?array
????{
????????return?[
????????????'page'?=>?$paginated['current_page'],
????????????'per_page'?=>?$paginated['per_page'],
????????????'total'?=>?$paginated['total'],
????????????'total_page'?=>?$paginated['last_page'],
????????];
????}

不過，如果你使用的是 Resource::collection($pageData) 方式，那么還需要額外自定義一個 ResourceCollection 類，并重寫對應 Resource 類的 collection 方法。

我通常會定義一個對應的基類，然后其它的都繼承它。也可以做個 trait，然后共用。

最后

其實，這個想法我很早就想提交的，但是我一直比較猶豫，這到底是不是一個很大眾的需求。不過我最后想明白了，這樣做既然能為我節(jié)省大量重復且危險的工作，有那么多的開發(fā)者，總會有人需要的，所以我提交了，同時也是驗證下我的想法到底是否可行，我的做法是否最優(yōu)，結(jié)果當然是我學到了很多，比如寫稍微復雜的測試用例。

另外，我想知道大家有沒其它方法，或你們是怎么對待不同情況的分頁信息的。

最后的最后，你如果也有好的想法，那么盡快提交吧！? ? ? ? ??? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

Atas ialah kandungan terperinci Laravel melaksanakan pengembalian maklumat halaman tersuai dengan Sumber!. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!