feat: add Next.js 15+ support (continuation) #87
Conversation
feat: add Next.js 15+ support
…pdate package.json, split tests
- replaced and with and for better clarity and alignment with Next.js conventions - simplified cookie transformation and validation functions to use - removed redundant type definitions and moved relevant types to a centralized file - improved error handling by formatting error messages for better readability - deleted unused file to reduce code duplication and maintain consistency across the codebase
src/index.ts
Outdated
|
|
||
| const getFn = (fnName: keyof typeof clientCookies, options?: OptionsType) => { | ||
| if (isClientSide(options)) { | ||
| if (getRenderPhase() === 'server') { |
There was a problem hiding this comment.
import { getCookie } from 'cookies-next'
export const TestComponent = () => {
const isActive = getCookie('active');
return (
<div>{isActive ? 'active': 'not active'}</div>
);
}it looks like we will have a difference between what the server and the client render.
Because getCookie always returns undefined on the server phase.
There was a problem hiding this comment.
Oh, although the current version most likely has the same behavior
There was a problem hiding this comment.
In my implementation, we simply return undefined when a function is designated for client-side use, and the client component calling it is being pre-rendered.
There was a problem hiding this comment.
It's worth mentioning that hasCookie always returns a boolean. In a client component during the server phase, it returns false instead of undefined. In my opinion, having a consistent return type is important for hasCookie.
There was a problem hiding this comment.
I see the issue now. One part of the problem is the mismatch between server and client. Additionally, if we use a function from the cookies-next import, we also encounter type-related issues:
Do you have any ideas on how to fix this?
|
@greg2012201 Thanks!
@joaopcm do you have any results? |
|
Thank you all for this it looks great :) However, I ran into this error while using it in my project: This happens for me when using |
@ck-euan You're absolutely right; I missed that and forgot to add the render phase check in the client-side functions. I've pushed a fix for this. @andreizanik @joaopcm Please test my changes again. I believe we're almost done. |
Co-authored-by: Andrei Zanouski <andreizaniK@gmail.com>
|
After my changes, we still encounter issues. Please refer to: #87 (comment) I'm considering whether we should implement hooks for the client side. We could maintain the old functions in asynchronous versions for the server side, along with hooks for the client side, all exported from a single What do you guys think? |
May be in next PR? This PR looks good to me |
@andreizanik I've added the last two commits to this PR. I updated the export functions to narrow down return types and updated the documentation to explain how to use cookies-next in client components without causing mismatch errors. Please check if everything works for you! PS: We can work on hooks in another PR. |
|
Today I published a new version. |
|
How can we make this work with Next.js Pages router as it was in v4? |
Hello! @andreizanik @joaopcm
I took over this PR #86 and successfully re-implemented smart imports to reduce dependency on
window.We now check options to determine if the function is being called on the client or server.
Additionally, we validate the presence of the
windowobject to identify the render phase of the client component:This step is necessary because, even if the function is designated for the client, Next.js attempts to use it during the server phase,
where objects like document are unavailable. This adjustment resolves environment-specific (server/client) errors.
I also encountered some issues with type compatibility. There was a type mismatch in NextRequest/NextResponse imported from
next/server.These class declarations include an
[INTERNALS]property of thesymboltype,which was required by our library but missing in the Next.js application when exported from
next/server.Although I haven’t identified the root cause, defining custom interfaces has resolved the issue:
All tests have passed, and I have manually tested the functionality with Next.js v15.0.1. Everything appears to work correctly.
Please review the code and conduct your own tests to ensure readiness for release.