pages/blog/index.tsx (3)

58-69: handlePageChange is called inside the effect but missing from the dependency array.

handlePageChange captures router and setCurrentPage in its closure and is invoked on line 66, but it's not listed as a dependency. This will trigger an exhaustive-deps lint warning.

Either wrap handlePageChange in useCallback and add it to the deps, or — per this repository's convention — add an eslint-disable comment explaining the omission.

Based on learnings, in the asyncapi/website repository, when you intentionally omit dependencies in React hooks, add an eslint-disable comment with an explanatory note.

Minimal fix — suppress with explanation

+  // eslint-disable-next-line react-hooks/exhaustive-deps -- handlePageChange is stable in behavior; only router.query.page and maxPage drive this effect
   }, [router.query.page, maxPage, currentPage]);

---

151-168: Use Array.length instead of Object.keys(…).length on arrays.

posts and currentItems are arrays. Object.keys(array) works but returns stringified indices — it's semantically misleading and marginally slower. Use .length directly.

Proposed diff

-          {Object.keys(posts).length === 0 && (
+          {posts.length === 0 && (
              ...
           )}
-          {Object.keys(posts).length > 0 && isClient && (
+          {posts.length > 0 && isClient && (
             <ul className='mx-auto mt-12 grid max-w-lg gap-5 lg:max-w-none lg:grid-cols-3'>
               {currentItems.map((post, index) => (
                 <BlogPostItem key={index} post={post} />
               ))}
             </ul>
           )}
-          {Object.keys(currentItems).length > 0 && !isClient && (
+          {currentItems.length > 0 && !isClient && (

---

43-56: Page change doesn't scroll to top.

After clicking a page number the viewport stays at the pagination bar near the bottom, forcing users to scroll up. Consider adding window.scrollTo(0, 0) (or scrolling to #main-content) inside handlePageChange.

Suggested addition

 const handlePageChange = (page: number) => {
   setCurrentPage(page);
+  window.scrollTo({ top: 0, behavior: 'smooth' });

   const currentFilters = { ...router.query, page: page.toString() };

components/pagination/PaginationItem.tsx (1)

26-36: Spread order: {...buttonProps} after className allows accidental override.

If a consumer passes className via the rest props, it will silently replace the component's own styling. Consider merging or reordering. Not a problem with current usages, just defensive.

components/helpers/usePagination.ts (1)

28-38: Uncontrolled mode: setCurrentPage accepts any number without bounds checking.

In uncontrolled mode, setInternalPage(nextPage) stores the raw value. Although safePage clamps it on the next render so currentItems and the returned currentPage are always valid, the internal state can drift out of bounds. This is a minor inconsistency — consider clamping before setting:

Optional improvement

-      setInternalPage(nextPage);
+      setInternalPage(Math.min(Math.max(nextPage, 1), maxPage || 1));

components/pagination/PaginationItem.tsx (2)

26-36: Add type="button" to prevent accidental form submission.

HTML <button> elements default to type="submit". If this component is ever rendered inside a <form>, clicking it would submit the form. Adding an explicit type="button" before the spread ensures safe defaults while still allowing overrides via buttonProps.

Proposed fix

     <button
+      type='button'
       onClick={() => onPageChange(pageNumber)}
       className={`font-inter font-normal relative flex size-8 items-center

---

28-31: Hardcoded hex colors bypass the Tailwind theme.

bg-[#6200EE] and text-[#141717] are magic values. If the project defines these as theme tokens (e.g., bg-primary-500, text-gray-900), prefer using those for consistency and easier future theming.

pages/blog/index.tsx (4)

59-71: Synchronous mutation inside useMemo — works but is fragile.

onFilterApply is designed to deliver results via a callback. Here you exploit the fact that it calls the callback synchronously to capture the result into a local let. This works today, but if onFilterApply ever becomes async (e.g., debounced or deferred), this will silently return stale/empty data.

A brief inline comment explaining the reliance on synchronous invocation would guard against future refactoring surprises.

---

72-77: totalPages duplicates what maxPage computes inside the hook.

totalPages (line 72) and maxPage (returned by usePagination) always produce the same value. totalPages is needed before calling the hook to derive queryPage, so it can't be eliminated entirely, but renaming or adding a short comment would clarify why two identical computations exist.

---

103-122: Filters change without resetting the page — potential UX confusion.

When a user is on, say, page 3 and applies a filter that still yields ≥3 pages, the URL retains ?page=3. Most pagination UIs reset to page 1 on a data-source change (filter applied/removed) so users see the most relevant results first. The out-of-bounds case is handled (page is clamped), but the in-bounds case silently keeps a stale page number.

Consider adding a useEffect that resets to page 1 whenever filters changes (and currentPage > 1):

Proposed approach

+  useEffect(() => {
+    if (!router.isReady) return;
+    if (Object.keys(filters).length === 0) return;
+    if (currentPage <= 1) return;
+
+    const nextQuery = { ...router.query };
+    delete nextQuery.page;
+    router.replace({ pathname: router.pathname, query: nextQuery }, undefined, { shallow: true, scroll: false });
+  }, [filters]);

---

215-226: Loader condition relies on currentItems.length > 0 but should mirror the data-present check.

Line 215 gates on filteredPosts.length > 0 && isClient to show posts. Line 222 gates on currentItems.length > 0 && !isClient to show the loader. If filteredPosts is non-empty but currentItems happens to be empty (theoretically shouldn't with current clamping, but defensive code should be symmetric), the loader would not display. For consistency, use filteredPosts.length > 0 && !isClient:

Proposed fix

-            {currentItems.length > 0 && !isClient && (
+            {filteredPosts.length > 0 && !isClient && (