내가 구현한 방식은
request 요청을 보낼 때마다 현재 페이지 정보를 pageNo
라는 것으로 같이 보내주었다.
위에서 받은 정보를 바탕으로
- 특정 날짜
- 단어
- url
등 해당하는 data들을 골라준 후에,
pageNO를 이용해서 slicing 해준 정보를 보내주었다.
위에서 request를 날릴 때마다
- maxPage (총 몇 페이지로 구성될지)
- left (앞으로 남은 페이지는 몇 페이지인지)
를 클라이언트에 넘겼다.
이 두 가지 정보는 아래 페이지 버튼이 총 5개일지, 남은게 5보다 적을 때는
그 이하로 렌더링할 지 결정하는 데에 사용하였다.
사진을 보면 loeft가 5 이하인 상황에서는 남은 페이지를 이용하여 버튼을 렌더링하고(동시에 '다음' 버튼을
disabled
시킨다.), 그 이외의 상황에서는 5개를 모두 렌더링 하는 것을 알 수 있다.
다음, 이전 버튼은 disabled 되어 있을 때는 작동하지 않고,
눌렀을 때 아예 request를 새로 날려 페이지를 이동시키는 것으로 구성하였고,
남은 데이터 수를 이용하여 버튼을 어떻게 렌더링 할지 결정하는 부분 중 생각나는 방법이 아예 새로운 rquest를 날리고, ejs 자체에 렌더링 로직을 구현하는 것이었다.
개별 페이지 버튼은 페이지 이동 없이 ajax 요청을 이용하여 html만 수정하는 방향으로 구성하였다.
내가 구현한 방식을 작동시켜보고
jquery datatable
을 작동시켰을 때 내가 구현한 부분이 너~~~무 마음에 들지 않았다. 모든 데이터를 요청하고 클라이언트 단에서 페이지네이션을 한 부분이 정말 인상 깊었다. 매우 빠르고 우아하다.
사실 이 부분은 조금 쉬운 편에 속했다.
내가 구현한 pagination 같은 경우는 page를 넘길 때마다 DB에 요청을 하고,
그 데이터를 넘어온 page 정보에 따라 slice
해서 보내는 방식으로 구현했)기 때문에 (비효율적....ㅠ),
request
요청을 보낼 때마다, 특정 text를 포함하는지 만 확인하면 되는 것이었다.