Laravel의 Pagination에 대한 가이드

Pagination은 웹 애플리케이션에서 일반적인 기능입니다. 내가 일한 거의 모든 라벨 애플리케이션은 어떤 형태의 페이지 매김이 구현되었습니다.

그러나 페이지 매김이란 무엇이며 왜 우리는 그것을 사용합니까? Laravel 애플리케이션에서 Pagination을 어떻게 구현할 수 있습니까? 그리고 우리는 어떤 페이지 매김 방법을 사용할 것인지 어떻게 결정합니까?

이 기사에서는 이러한 질문에 대답하고 블레이드 뷰와 API 엔드 포인트 모두에 Laravel에서 Pagination을 사용하는 방법을 탐구 할 것입니다. 이 기사가 끝날 무렵, 당신은 자신의 프로젝트에서 Pagination을 사용하기에 충분히 확신해야합니다. . #페이지 매김은 무엇입니까? Pagination은 큰 데이터 세트를 작은 청크 (또는 페이지)로 나누는 데 사용되는 기술입니다. 한 번에 가능한 모든 값보다는 데이터의 하위 집합을 표시 할 수 있습니다. 예를 들어 의 경우 애플리케이션에서 모든 사용자의 이름을 출력하는 페이지가 있다고 상상해보십시오. 수천 명의 사용자가 있다면 단일 페이지에 모두 표시하는 것이 실용적이지 않습니다. 대신 Pagination을 사용하여 각 페이지에서 사용자의 하위 집합 (예 : 10 명)을 표시하고 사용자가 페이지를 탐색하여 더 많은 사용자 (다음 10)를 볼 수 있습니다. Pagination을 사용하여 다음과 같이 할 수 있습니다

응용 프로그램의 성능 향상 - 한 번에 더 작은 데이터 세트를 가져 오기 때문에 데이터베이스에서 가져오고 프로세스/변환을 가져온 다음 반환 할 데이터가 적습니다. 사용자 경험 향상 - 사용자는 한 번에 작은 데이터의 작은 하위 집합에만 관심을 가질 가능성이 높습니다 (일반적으로 필터 및 검색어가 사용되는 경우 처음 몇 페이지에서 볼 수 있습니다). Pagination을 사용하면 사용자가 관심이없는 데이터 표시를 피할 수 있습니다. 페이지 로딩 시간 개선 - 한 번에 데이터의 하위 집합 만 가져와서 페이지에로드 해야하는 데이터의 양을 줄일 수있어 페이지로드 및 JavaScript 처리 시간을 개선 할 수 있습니다.

.

페이지 매김은 일반적으로 두 가지 다른 유형으로 나눌 수 있습니다 :

오프셋 기반 페이지 매김 - 이것은 웹 앱, 특히 UI (User Interfaces)에서 볼 수있는 가장 일반적인 유형의 페이지 매력입니다. 여기에는 "오프셋"및 "제한"을 기반으로 데이터베이스에서 데이터의 서브 세트를 가져 오는 것이 포함됩니다. 예를 들어, 20 번째 레코드에서 시작하여 10 개의 레코드를 가져와 3 번째 데이터를 가져올 수 있습니다. 커서 기반 페이지 매김 -이 유형의 페이지 매김에는 "커서"를 기반으로 데이터의 하위 집합을 가져 오는 것이 포함됩니다. 커서는 일반적으로 데이터베이스의 레코드에 대한 고유 식별자입니다. 예를 들어, 레코드에서 ID가 20으로 시작하는 다음 10 개의 레코드를 가져올 수 있습니다.

Laravel은 응용 프로그램에서 웅변 쿼리를 페이지를 찍기위한 세 가지 다른 방법을 제공합니다.

• - 오프셋 기반 페이지 매김을 사용하고 데이터 세트의 총 레코드 수를 가져옵니다. paginate - 오프셋 기반 페이지 매김을 사용하지만 데이터 세트의 총 레코드 수를 가져 오지 않습니다. - 커서 기반 페이지 매김을 사용하고 데이터 세트의 총 레코드 수를 가져 오지 않습니다.
이 각 방법을 더 자세히 살펴 보겠습니다.
• #simplePaginate 메서드
메소드를 사용하면 오프셋 및 제한을 기반으로 데이터베이스에서 데이터의 하위 집합을 가져올 수 있습니다 (기본 SQL 쿼리를 볼 때 나중에 살펴 보겠습니다). 당신은
• 방법을 사용할 수 있습니다 cursorPaginate 위의 코드를 실행하면
가 일반적으로 메소드는 URL의 를 방문하면

메소드가 데이터의 두 번째 페이지를 가져옵니다.

기본적으로, Laravel 기본의 모든 페이지 매김 방법은 한 번에 15 개의 레코드를 가져 오기 위해 기본적으로 기본적으로 기본적으로. 그러나 이것은 다른 값으로 변경 될 수 있습니다 (나중에이 작업을 수행하는 방법을 살펴 보겠습니다). #using 블레이드 뷰가있는 블레이드 뷰에서 데이터를 렌더링 할 때 paginate 메소드를 사용하는 방법을 살펴 보겠습니다. 우리는 데이터베이스에서 사용자를 페이지에 입은 형식으로 가져 와서보기로 전달하는 간단한 경로를 가지고 있다고 상상해보십시오.

우리의 파일은 다음과 같이 보일 수 있습니다 paginate 결과 페이지는 다음과 같습니다

블레이드 뷰에서 일어나는 일을 분해합시다

우리는
• 필드에있는 각 사용자를 통해 루프를하고 있으며 ( 우리는 $users 객체에서 IlluminatePaginationLengthAwarePaginator 메소드를 호출합니다. 이것은 Pagination 링크 (예 : "previous", "next"및 페이지 번호)를 표시하는 일부 HTML을 반환하는 편리한 방법입니다. 즉, Pagination Links를 직접 작성하는 것에 대해 걱정할 필요가 없으며 Laravel은 모든 것을 처리 할 것입니다.
.
• 우리는 또한 links 메소드가 우리에게 페이지 매김 데이터에 대한 개요를 제공하고 있음을 알 수 있습니다. 우리는 총 50 개의 레코드 중 16 ~ 30 번째 기록을보고 있음을 알 수 있습니다. 우리는 또한 우리가 두 번째 페이지에 있고 총 4 페이지가 있음을 알 수 있습니다. $users
메소드는 테일 윈드 CSS를 사용하여 HTML 스타일을 반환한다는 점에 유의해야합니다. Tailwind 이외의 것을 사용하고 싶거나 Pagination 링크를 스스로 스타일링하려면 Pagination views 사용자 정의에 대한 문서를 확인할 수 있습니다.

. API 엔드 포인트에서 #using

는 블레이드 뷰에서 paginate 메소드를 사용하면 API 엔드 포인트에서도 사용할 수도 있습니다. Laravel은 Paginated 데이터를 JSON으로 자동 변환 하여이 프로세스를 쉽게 만듭니다. 예를 들어, 는 엔드 포인트를 빌드 할 수 있습니다 ( 파일에 다음 경로를 추가하여 페이지에 입은 사용자를 JSON 형식으로 반환합니다.

엔드 포인트에 액세스하면 다음과 비슷한 JSON 응답을 반환합니다 (links 필드를 간결성을 위해 단 3 개의 레코드로 제한) :

.

JSON 응답을 분해합시다 :

- 현재 페이지입니다. 이 경우 우리는 첫 페이지에 있습니다.
• - 실제 데이터 자체가 반환되고 있습니다. 이 경우 처음 15 명의 사용자가 포함되어 있습니다 (간결성은 3으로 단축). current_page - 데이터의 첫 페이지에 대한 URL.
• - 리턴되는 데이터의 시작 레코드 번호. 이 경우 첫 번째 레코드입니다. 우리가 두 번째 페이지에 있다면 이것은 16 일입니다. data
- 데이터의 총 페이지 수. 이 경우 4 페이지가 있습니다.
• - 데이터의 마지막 페이지에 대한 URL. first_page_url - 다른 데이터 페이지에 대한 링크 배열. 여기에는 "이전"및 "다음"링크와 페이지 번호가 포함됩니다.
- 데이터의 다음 페이지에 대한 URL.
• from - 엔드 포인트의 기본 URL - 페이지 당 반환되는 레코드 수. 이 경우 15.
• - 이전 데이터의 이전 페이지에 대한 URL. 이 경우 첫 페이지에 있기 때문에 last_page입니다. 우리가 두 번째 페이지에 있다면 이것은 첫 번째 페이지의 URL입니다.
- 반환되는 데이터의 종료 레코드 번호. 이 경우 15 번째 기록입니다. 우리가 두 번째 페이지에 있었다면 이것은 30입니다.
• last_page_url - 데이터 세트의 총 레코드 수입니다. 이 경우 50 개의 레코드가 있습니다.
• #기본 SQL 쿼리 Laravel에서 links 메소드를 사용하면 두 개의 SQL 쿼리가 실행됩니다.
첫 번째 쿼리는 데이터 세트의 총 레코드 수를 가져옵니다. 이것은 총 페이지 수 및 총 레코드 수와 같은 정보를 결정하는 데 사용됩니다. 두 번째 쿼리는 오프셋 및 제한 값에 따라 데이터의 하위 집합을 가져옵니다. 예를 들어, 사용자가 처리하고 반환하기 위해 사용자를 가져 오는 것일 수 있습니다.
• . next_page_url 따라서 사용자의 첫 번째 페이지 (페이지 당 15 명)를 가져 오려면 다음 SQL 쿼리가 실행됩니다.
• 및 path 두 번째 쿼리에서
값이 15로 설정되어 있음을 알 수 있습니다. 이것은 페이지 당 반환되는 레코드 수입니다.
• per_page 값은 다음과 같이 계산됩니다
따라서 사용자의 세 번째 페이지를 가져오고 싶다면
• 값은 다음과 같이 계산됩니다. prev_page_url 따라서 null
• 및

  <!-- Syntax highlighted by torchlight.dev -->use App\Models\User;
  
  $users = User::query()->paginate();
  

  # 메서드 simplePaginate 방법은 메소드와 매우 유사하지만 한 가지 주요 차이점이 있습니다.

  메소드는 데이터 세트의 총 레코드 수를 가져 오지 않습니다. simplePaginate 방금 본 바와 같이 paginate 메소드를 사용할 때 데이터 세트에서 사용 가능한 총 레코드 수 및 페이지에 대한 정보도 얻습니다. 그런 다음이 정보를 사용하여 UI 또는 API 응답의 총 페이지 수와 같은 것을 표시 할 수 있습니다. 그러나 이러한 세부 정보를 사용자 (또는 API를 소비하는 개발자)에게 표시하지 않으려면 메소드를 사용하여 불필요한 데이터베이스 쿼리 (총 레코드 수를 계산 함)를 피할 수 있습니다. simplePaginate 메소드는

  메소드와 같은 방식으로 사용할 수 있습니다.

  위의 코드를 실행하면 가 paginate의 인스턴스가 될 수 있습니다. 메소드에 의해 리턴 된 객체와 달리 객체에는 데이터 세트의 총 레코드 수에 대한 정보가 포함되어 있지 않으며 얼마나 많은 페이지 또는 총 레코드가 있는지 모릅니다. 데이터의 현재 페이지와 가져올 레코드가 더 있는지 여부에 대해 알고 있습니다.

  #using 블레이드 뷰가있는 블레이드 뷰와 함께 simplePaginate 메소드를 어떻게 사용하는지 살펴 보겠습니다. 우리는 이전과 같은 경로를 가지고 있다고 가정하지만 이번에는

메소드를 사용하고 있습니다 : .

우리는 이전과 같은 방식으로 블레이드 뷰를 만들 것입니다 : simplePaginate 결과 페이지는 다음과 같습니다 paginate

이 예에서 볼 수 있듯이 의 출력은 메소드를 사용할 때 본 출력과 다릅니다. 메소드는 총 레코드 수를 가져 오지 않기 때문에 총 페이지 나 레코드 수의 컨텍스트가 없으며 다음 페이지가 있는지 여부에 관계 없이만. 그러므로 우리는 페이지 매김 링크에서 "이전"및 "다음"링크 만 볼 수 있습니다. API 엔드 포인트에서 #using

<!-- Syntax highlighted by torchlight.dev -->use App\Models\User;
use Illuminate\Support\Facades\Route;

Route::get('users', function () {
    $users = User::query()->paginate();

    return view('users.index', [
        'users' => $users,
    ]);
});

API 엔드 포인트에서

메소드를 사용할 수도 있습니다. Laravel은 Paginated Data를 자동으로 JSON으로 변환합니다. $users IlluminateContractsPaginationPaginator IlluminatePaginationPaginator 엔드 포인트를 빌드하여 Paginated 사용자를 JSON 형식으로 반환합니다.

<!-- Syntax highlighted by torchlight.dev -->use App\Models\User;

$users = User::query()->paginate();

우리 가이 경로를 쳤을 때, 우리는 다음과 비슷한 JSON 응답을 얻게 될 것이다 (

필드를 Brevity를 위해 단 3 개의 레코드로 제한) : data.

우리가 볼 수 있듯이, JSON 응답은 메소드를 사용할 때 얻은 응답과 매우 유사합니다. 주요 차이점은 응답에

<!-- Syntax highlighted by torchlight.dev -->use App\Models\User;
use Illuminate\Support\Facades\Route;

Route::get('users', function () {
    $users = User::query()->paginate();

    return view('users.index', [
        'users' => $users,
    ]);
});

,

, paginate 또는 필드가 없다는 것입니다. #기본 SQL 쿼리 last_page 메소드를 사용할 때 실행되는 기본 SQL 쿼리를 살펴 보겠습니다. last_page_url 메소드는 여전히 데이터베이스에서 데이터의 하위 집합을 가져 오기 위해 links 및 total 값에 의존합니다. 그러나 데이터 세트의 총 레코드 수를 가져 오기 위해 쿼리를 실행하지 않습니다.

값은 이전과 같은 방식으로 여전히 계산됩니다.

그러나 그러나

값은 simplePaginate 메소드와 약간 다르게 계산됩니다. 다음과 같이 계산됩니다

이는

메소드가 가져올 레코드가 더 있는지 판단하기 위해 simplePaginate 값보다 한 번 더 레코드를 가져와야하기 때문입니다. 예를 들어, 페이지 당 15 개의 레코드를 가져오고 있다고 가정 해 봅시다. limit 값은 16 개입니다. 따라서 16 개의 레코드를 반환하려면 가져 오는 데 사용할 수있는 데이터가 하나 이상 있다는 것을 알고 있습니다. 16 개 미만의 레코드가 반환되면 데이터의 마지막 페이지에 있다는 것을 알고 있습니다. 따라서 사용자의 첫 번째 페이지 (페이지 당 15 명)를 가져 오려면 다음 SQL 쿼리가 실행됩니다. offset 두 번째 페이지의 쿼리는 그렇게 보일 것입니다 :

#offset 메서드 지금까지 우리는 오프셋 기반 페이지 매김을 모두 사용하는 및

메소드를 살펴 보았습니다. 우리는 이제 커서 기반 페이지 매김을 사용하는

<!-- Syntax highlighted by torchlight.dev --><html>
<head>
    <title>Paginate</title>
    <script src="https://cdn.tailwindcss.com"></script>
</head>

<body>
    <div class="max-w-5xl mx-auto py-8">
        <h1 class="text-5xl">Paginate</h1>

        <ul class="py-4">
            @foreach ($users as $user)
                <li class="py-1 border-b">{{ $user->name }}</li>
            @endforeach
        </ul>

        {{ $users->links() }}
    </div>
</body>
</html>

메소드를 살펴볼 것입니다. 헤드 업으로서 커서 기반의 페이지 매김은 처음 만났을 때 약간 혼란스러워 보일 수 있습니다. 그러니 바로 그것을 얻지 못하더라도 걱정하지 마십시오. 바라건대,이 기사가 끝날 무렵, 당신은 그것이 어떻게 작동하는지 더 잘 이해할 수 있기를 바랍니다. 또한이 기사의 끝에 커서 기반의 페이지 매김을 더 자세히 설명하는 멋진 비디오를 남겨 둘 것입니다. 오프셋 기반 Pagination을 사용하면

및 limit 값을 사용하여 데이터베이스에서 데이터의 하위 집합을 가져옵니다. 그래서 우리는 "처음 10 개의 레코드를 건너 뛰고 다음 10 개의 레코드를 가져 오십시오"라고 말할 수 있습니다. 이해하기 간단하고 구현하기 쉽습니다. Cursor Pagination을 사용하면 이전/다음 레코드 세트를 가져 오기 위해 커서 (일반적으로 데이터베이스의 특정 레코드에 대한 고유 식별자)를 사용합니다.예를 들어 첫 15 명의 사용자를 가져 오기 위해 쿼리를한다고 가정 해 봅시다. 15 번째 사용자의 ID가 20이라고 가정합니다. 다음 15 명의 사용자를 가져 오려면 15 번째 사용자 (20)의 ID를 커서로 사용합니다. 우리는 "ID가 20보다 큰 다음 15 명의 사용자를 가져 오십시오"라고 말할 것입니다.

당신은 때때로 "토큰", "키", "다음", "이전"등이라고하는 커서를 볼 수 있습니다. 그것들은 본질적으로 데이터베이스의 특정 레코드에 대한 참조입니다. 우리는 기본 SQL 쿼리를 살펴볼 때이 섹션 후반부의 커서의 구조를 살펴 봅니다.

. laravel은

메소드와 함께 커서 기반 페이지 매김을 쉽게 사용할 수 있습니다.

위의 코드를 실행하면 필드가 <p>, 일반적으로 <code>cursorPaginate 객체의 인스턴스가됩니다. 이 페이지 인자 인스턴스에는 응용 프로그램에 페이지 진화 데이터를 표시하는 데 필요한 모든 정보가 포함되어 있습니다. 메소드와 유사하게

메소드는 데이터 세트의 총 레코드 수를 가져 오지 않습니다. 현재 데이터 페이지와 가져올 레코드가 더 있는지 여부에 대해서만 알고 있으므로 총 페이지 나 레코드 수를 즉시 알지 못합니다. #using 블레이드 뷰가있는 <!-- Syntax highlighted by torchlight.dev -->use App\Models\User; $users = User::query()->paginate(); 블레이드 뷰에서 데이터를 렌더링 할 때

메소드를 사용하는 방법을 살펴 보겠습니다. 이전 예제와 마찬가지로 데이터베이스에서 사용자를 페이지에 빠지게하는 간단한 경로가 있다고 가정합니다. $users 블레이드 뷰는 다음과 같이 보일 수 있습니다 IlluminateContractsPaginationCursorPaginator 이것은 다음과 비슷한 페이지를 출력합니다 : IlluminatePaginationCursorPaginator

우리가 볼 수 있듯이, 메소드는 데이터 세트의 총 레코드 수를 가져 오지 않기 때문에

의 출력은 메소드를 사용할 때 본 출력과 유사합니다. 우리는 페이지 매김 링크에서 "이전"및 "다음"링크 만 볼 수 있습니다. simplePaginate API 엔드 포인트에서 #using cursorPaginate 메소드를 사용할 수 있으며 Paginated Data를 자동으로 JSON으로 변환합니다.

cursorPaginate 엔드 포인트를 빌드하여 Paginated 사용자를 JSON 형식으로 반환합니다.

우리 가이 경로를 쳤을 때, 우리는 다음과 비슷한 JSON 응답을 얻게 될 것이다 (

필드를 Brevity를 위해 단 3 개의 레코드로 제한) : cursorPaginate.

<!-- Syntax highlighted by torchlight.dev -->use App\Models\User;

$users = User::query()->paginate();

우리가 볼 수 있듯이, JSON 응답은 우리가 본 이전 응답과 유사하지만 약간의 차이가 있습니다. 우리는 총 레코드 수를 가져 오지 않기 때문에 응답에 ,

, last_page 또는 last_page_url 필드가 없습니다. 당신은 또한 우리가 links 및 total 필드도 없다는 것을 알았을 수도 있습니다. 대신, 우리는 다음과 이전 데이터 페이지의 커서를 포함하는 및 from 필드가 있습니다. 우리가 첫 페이지에 있기 때문에 to 및 필드는 둘 다

입니다. 그러나

및 next_cursor 필드가 설정되어 있습니다 prev_cursor 필드는 다음 페이지의 커서를 포함하는 Base-64 인코딩 된 문자열입니다. 우리가 필드를 디코딩하면 이와 같은 것을 얻을 수 있습니다 (가독성을 위해 아름답게) : prev_cursor 커서에는 두 개의 개별 정보가 포함되어 있습니다 : prev_page_url null - 데이터 세트에서 가져온 마지막 레코드의 ID. next_cursor - 커서가 다음 또는 이전 항목 세트를 가리키는지를 알려주는 부울 값. 값이 인 경우 커서를 사용하여 다음 레코드 세트를 next_page_url 값보다 큰 ID로 가져와야합니다. 값이 인 경우 커서를 사용하여 이전 레코드 세트를

값보다 적은 ID로 가져와야합니다.

두 번째 데이터 페이지가 어떻게 보일지 살펴 보겠습니다 (다시, 간단함을 위해 3 개의 레코드로 단축) : next_cursor 우리는 및 필드가 설정되었고 및 next_cursor 필드가 다음 페이지의 커서로 업데이트되었음을 ​​알 수 있습니다. #기본 SQL 쿼리 Cursor Pagination이 후드 아래에서 어떻게 작동하는지 더 잘 이해하려면

메소드를 사용할 때 실행되는 기본 SQL 쿼리를 살펴 보겠습니다. 데이터의 첫 페이지 (15 레코드 포함)에서 다음 SQL 쿼리가 실행됩니다.

<!-- Syntax highlighted by torchlight.dev -->use App\Models\User;
use Illuminate\Support\Facades\Route;

Route::get('users', function () {
    $users = User::query()->paginate();

    return view('users.index', [
        'users' => $users,
    ]);
});

우리는 우리가

테이블에서 처음 16 개의 레코드를 가져오고 열에 따라 오름차순 순서로 주문하고 있음을 알 수 있습니다.

메소드와 마찬가지로, 우리는 더 많은 레코드가 있는지 확인하고 싶기 때문에 16 행을 가져오고 있습니다. 그런 다음 다음 커서가있는 항목의 다음 페이지로 이동한다고 상상해 봅시다.

이 커서가 디코딩되면 다음 JSON 객체를 얻습니다.
• 그런 다음 Laravel은 다음 SQL 쿼리를 실행하여 다음 레코드 세트를 가져옵니다.

  <!-- Syntax highlighted by torchlight.dev -->use App\Models\User;
  
  $users = User::query()->paginate();
  

  우리가 볼 수 있듯이, 우리는

  테이블에서 15보다 큰 users 테이블에서 다음 16 개의 레코드를 가져오고 있습니다 (15는 이전 페이지의 마지막 ID 이후). 이제 2 페이지의 첫 번째 사용자의 ID가 16이라고 가정 해 봅시다. 두 번째 페이지의 첫 번째 데이터 페이지로 다시 탐색하면 다음 커서가 사용됩니다. id 이것이 디코딩되면 다음 JSON 객체를 얻습니다.

  결과의 다음 페이지로 이동하면 마지막 레코드가 커서로 사용됩니다. 우리가 이전 결과의 이전 페이지로 돌아 가면 첫 번째 레코드를 가져 오는 것이 커서로 사용됩니다. 이러한 이유로, 우리는

  값이 커서에서 16으로 설정되어 있음을 알 수 있습니다. 우리는 또한 로 설정되어 있음을 알 수 있습니다. 왜냐하면 우리는 이전 항목 세트로 돌아 가기 때문입니다.

  <!-- Syntax highlighted by torchlight.dev -->use App\Models\User;
  use Illuminate\Support\Facades\Route;
  
  Route::get('users', function () {
      $users = User::query()->paginate();
  
      return view('users.index', [
          'users' => $users,
      ]);
  });
  

  . 결과적으로, 다음 SQL 쿼리는 이전 레코드 세트를 가져 오기 위해 실행됩니다.

  우리가 볼 수 있듯이

  제약 조건은 이제 16보다 적은

  <!-- Syntax highlighted by torchlight.dev --><html>
  <head>
      <title>Paginate</title>
      <script src="https://cdn.tailwindcss.com"></script>
  </head>
  
  <body>
      <div class="max-w-5xl mx-auto py-8">
          <h1 class="text-5xl">Paginate</h1>
  
          <ul class="py-4">
              @foreach ($users as $user)
                  <li class="py-1 border-b">{{ $user->name }}</li>
              @endforeach
          </ul>
  
          {{ $users->links() }}
      </div>
  </body>
  </html>
  

  (16이 2 페이지의 첫 번째 ID 이후)로 레코드를 점검하고 결과는 내림차순으로 주문됩니다. Pagination을 사용하여 API 리소스를 사용하는 지금까지 API 예제에서 방금 컨트롤러에서 페이지를 입은 데이터를 직접 반환했습니다. 그러나 실제 응용 프로그램에서는 데이터를 사용자에게 되돌리기 전에 데이터를 처리하고 싶을 것입니다. 이는 필드를 추가하거나 제거하거나 데이터 유형을 변환하거나 데이터를 다른 형식으로 변환하는 것입니다. 이러한 이유로 API 리소스가 데이터를 반환하기 전에 지속적으로 변환 할 수있는 방법을 제공하기 때문에 API 리소스를 사용하고 싶을 것입니다. Laravel을 사용하면 Pagination과 함께 API 리소스를 사용할 수 있습니다. 이 작업을 수행하는 방법의 예를 살펴 보겠습니다.

  우리는 사용자 데이터를 반환하기 전에 변환하는 users.id API 리소스 클래스를 생성했다고 상상해보십시오. 다음과 같이 보일 수 있습니다 : _pointsToNextItems false

  방법에서

  메소드에서, 우리는이 리소스를 통해 사용자를 처리 할 때마다 , 및

  필드 만 반환하려고합니다. 이제

  <!-- Syntax highlighted by torchlight.dev -->use App\Models\User;
  use Illuminate\Support\Facades\Route;
  
  Route::get('paginate', function () {
      return User::query()->paginate();
  });
  

  : 를 사용하여 페이지 진화물 사용자를 반환하는 API 엔드 포인트를 구축합시다.

  위의 코드에서 데이터베이스에서 단일 페이지 (15 명의 사용자가 포함 된 첫 페이지라고 가정 해 봅시다)를 가져오고 있습니다. 그런 다음 필드 (where의 인스턴스가 될 것임)를 메소드로 전달합니다. 이 메소드는 id를 사용하여 페이지를 사용하여 사용자에게 반환하기 전에 페이지 진화 데이터를 변환합니다. 우리가

  엔드 포인트를 쳤을 때, 우리는 다음과 비슷한 JSON 응답을 얻게 될 것이다 (/api/users 필드를 간결성을 위해 단 3 개의 레코드로 제한) : data.

  위의 JSON에서 볼 수 있듯이 Laravel은 우리가 Paginated DataSet과 함께 작업하고 Paginated 데이터를 이전과 유사한 형식으로 반환한다는 것을 감지합니다. 그러나 이번에는 필드의 사용자는 API 리소스 클래스에 지정된 ,

  <!-- Syntax highlighted by torchlight.dev -->use App\Models\User;
  
  $users = User::query()->paginate();
  

  및 필드 만 포함합니다. 다른 필드 (,

  , data, id, , , name 및 )는 여전히 페이지의 데이터의 일부로 여전히 반환되지만 필드 내부에 배치되었습니다. email, , current_page 및 from 링크가 다른 데이터의 데이터에 대한 링크를 포함하는 필드도 있습니다. #페이지 당 값을 변경합니다 Paginated 데이터로보기를 구축 할 때 사용자가 페이지 당 표시되는 레코드 수를 변경할 수 있습니다. 이것은 드롭 다운 또는 숫자 입력 필드를 통한 것일 수 있습니다. last_page , 및 매개 변수를 전달하여 페이지 당 표시되는 레코드 수를 쉽게 변경할 수 있습니다. 이 매개 변수는 페이지 당 표시 할 레코드 수를 지정할 수 있습니다. links

위의 예에서 메소드의 path 매개 변수로 전달합니다. 그런 다음 이러한 다른 URL에 액세스 할 수 있습니다 per_page - 페이지 당 10 개의 레코드가있는 사용자의 첫 페이지를 표시합니다. to - 페이지 당 5 개의 레코드가있는 사용자의 첫 페이지를 표시합니다. total meta - 페이지 당 5 개의 레코드가있는 사용자의 두 번째 페이지를 표시합니다. <...> 등 ... links #first를 사용할 페이지 매김 방법을 결정하는 방법 이제 우리는 다양한 유형의 페이지 매김과 Laravel에서 사용하는 방법을 살펴 보았으므로 응용 프로그램에서 사용할 수있는 접근법을 결정하는 방법에 대해 논의 할 것입니다. ##페이지 번호 또는 총 레코드 번호가 필요합니까? last 총 레코드 또는 페이지 수를 표시 해야하는 UI 또는 API 엔드 포인트를 구축하는 경우 prev 메소드는 아마도 현명한 선택 일 것입니다.이 중 하나를 필요로하지 않으면

또는 simplePaginate가 총 레코드 수를 계산하기 위해 불필요한 쿼리를 수행하지 않기 때문에 더 효율적입니다. ##특정 페이지로 점프해야합니까? cursorPaginate 특정 데이터 페이지로 점프 할 수 있어야한다면 오프셋 기반 페이지 매김이 더 적합합니다. Cursor Pagination은 상태가 높기 때문에 다음 페이지에 의존하여 다음에 어디로 가야할지 알 수 있습니다. 따라서 특정 페이지로 이동하는 것은 쉽지 않습니다.

오프셋 페이지 매김을 사용할 때는 일반적으로 요청의 페이지 번호를 전달하고 (쿼리 매개 변수로) 이전 페이지의 컨텍스트없이 해당 페이지로 점프 할 수 있습니다. ##How How는 데이터 세트가 얼마나 큰가?

데이터베이스가

값을 처리하는 방식으로 인해 페이지 번호가 증가함에 따라 오프셋 기반 페이지 매김이 덜 효율적입니다. 오프셋을 사용할 때 데이터베이스는 여전히 모든 레코드를 오프셋 값까지 스캔해야하기 때문입니다. 그들은 쿼리 결과에서 버려졌고 반환되지 않습니다.

다음은 이것을 더 자세히 설명하는 훌륭한 기사입니다. https://use-the-index-luke.com/no-porporpset. 데이터베이스의 총 데이터 양이 커지고 페이지 번호가 증가함에 따라 오프셋 기반 페이지 매김이 덜 효율적일 수 있습니다. 이 경우, Cursor 기반의 페이지 매김은 더 성능이 뛰어납니다. 특히 이전 레코드를 읽지 않기 때문에 Cursor 필드가 색인화 된 경우 특히. 이러한 이유로 대규모 데이터 세트에 대한 Pagination을 사용하려는 경우 오프셋 Pagination에 대한 커서 페이지 매김을 선택할 수 있습니다. ##데이터 세트가 자주 변경 될 가능성이 있습니까?

기본 데이터 세트가 요청간에 변경되면 오프셋 기반 페이지 매김이 문제로 어려움을 겪을 수 있습니다. 예를 살펴 보겠습니다. 데이터베이스에 다음 10 명의 사용자가 있다고 가정 해 봅시다.

사용자 1

사용자 2

offset 사용자 3 사용자 4

사용자 5

사용자 6

사용자 7 사용자 8

사용자 9 사용자 10

우리는 첫 페이지를 가져 오도록 요청하고 (5 명의 사용자가 포함되어 있음) 다음 사용자를 얻습니다.

사용자 1

• 사용자 2
• 사용자 3 사용자 4
• 사용자 5
• 2 페이지로 이동하면 사용자가 6 ~ 10을 얻을 것으로 예상됩니다. 그러나 2 페이지를로드하기 전에 (여전히 페이지 1을보고있는 동안) 사용자 1이 데이터베이스에서 삭제된다고 상상해 봅시다. 페이지 크기는 5이므로 다음 페이지를 가져 오는 쿼리는 다음과 같습니다.
이것은 우리가 처음 5 개의 레코드를 건너 뛰고 다음 5를 가져 오는 것을 의미합니다. 이로 인해 다음 사용자가 포함 된 페이지 2가 발생합니다.
사용자 7 사용자 8
• 사용자 9 사용자 10
우리가 볼 수 있듯이 사용자 6은 목록에서 누락되었습니다. 이것은 사용자 6이 이제 테이블에서 5 번째 레코드이기 때문에 실제로 첫 페이지에 있습니다. . 커서 기반의 페이지 매김에는이 문제가 없습니다. 우리는 레코드를 건너 뛰지 않기 때문에 커서를 기반으로 다음 레코드 세트를 가져오고 있습니다. 위의 예에서 커서 기반 페이지 매김을 사용했다고 상상해 봅시다. 2 페이지의 커서는 첫 번째 페이지의 마지막 레코드이기 때문에 사용자 5의 ID (5라고 가정 할 것입니다)입니다. 따라서 2 페이지의 쿼리는 다음과 같습니다.

위의 쿼리를 실행하면 예상대로 사용자 6 ~ 10을 반환합니다. 이것은 기본 데이터가 읽거나 추가되거나 읽을 때 오프셋 기반 페이지 매김이 어떻게 문제가 될 수 있는지를 강조해야합니다. 예측하기 어려워지고 예상치 못한 결과로 이어질 수 있습니다.

#API를 만들 수 있습니까? 응용 프로그램에서 단일 유형의 페이지 매김을 사용하는 데 고정되어 있지 않다는 것을 기억하는 것이 중요합니다. 어떤 곳에서는 오프셋 페이지 매김이 더 적합 할 수 있으며 (UI 목적으로) 커서 페이지 매김이 더 효율적 일 수 있습니다 (예 : 큰 데이터 세트로 작업 할 때). 따라서 유스 케이스에 따라 응용 프로그램에서 페이지 매김 방법을 혼합하고 일치시킬 수 있습니다.

<!-- Syntax highlighted by torchlight.dev -->use App\Models\User;

$users = User::query()->paginate();

그러나 API를 구축하는 경우 일관되고 모든 엔드 포인트에 대한 단일 페이지 매김 접근 방식을 사용하는 것이 좋습니다. 이를 통해 개발자가 API 사용 방법을 이해하고 혼란을 피할 수 있습니다. 당신은 그들이 어떤 엔드 포인트를 오프셋-지분을 사용하고 cursor-pagination을 사용하는지 기억하기를 원하지 않습니다. 물론, 이것은 어렵고 빠른 규칙이 아닙니다. 하나의 특정 엔드 포인트에서 다른 페이지 매김 방법을 사용해야한다면 계속 진행하십시오. 그러나 개발자가 더 쉽게 이해할 수 있도록 문서를 명확하게하십시오. . #대신 비디오를 예약합니까? 시각적 학습자라면 Aaron Francis 의이 멋진 비디오를 확인하고 오프셋과 커서 기반 페이지 매력의 차이점을 더 자세히 설명 할 수 있습니다.

#conclusion 이 기사에서는 Laravel의 다양한 유형의 페이지 매김과 사용 방법을 살펴 봅니다. 또한 기본 SQL 쿼리와 응용 프로그램에서 사용할 페이지 매김 방법을 결정하는 방법을 살펴 보았습니다. 희망적으로, 당신은 이제 당신의 laravel 애플리케이션에서 Pagination을 사용하는 것에 대해 더 자신감을 가져야합니다. .

위 내용은 Laravel의 Pagination에 대한 가이드의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!