Where are you looking at warnings?

Where are you looking at warnings?

sorry I missed this. what do you mean exactly? The warnings show up in my IDE if that is what you mean

getting the same warning in the same situation. Using Webstorm

I have the same issue in WebStorm. It is annoying.
I am not sure about the warning, but it seems like there's no problem when I build the project for deployment.

Plus, the problem will disappear after changing the code above in this way.

from

const myComponent = ({ myFunc }: myProps) => {
  myFunc();
  return <></>;
};

to

const myComponent = (myWorkingProps: myProps) => {
  myWorkingProps.myFunc();
  return <></>;
};

myWorkingProps can be any arbitrary word.

I have this warning on VSCode too.

Another annoying thing about this warning is that if the parent component is client component, removing the "use client" directive from the child component will resolve this warning, although the child component still will be a client component.

removing the "use client" directive from the child component will resolve this warning,

That is the intended fix for this warning

although the child component still will be a client component.

That is how Next.js works

To me, it is important that I label all client components with the 'use client' directive.

Our editors should either be smart enough to figure out that only parent components are also client components, so that there is no error, or else our IDEs shouldn't complain at all.

In my opinion, Next.js should allow us to turn off this warning TS71007 in tsconfig.json (or somewhere else).

To me, it is important that I label all client components with the 'use client' directive.

Our editors should either be smart enough to figure out that only parent components are also client components, so that there is no error, or else our IDEs shouldn't complain at all.

In my opinion, Next.js should allow us to turn off this warning TS71007 in tsconfig.json (or somewhere else).

This is incorrect usage. Components marked with the "use client" should not (because they cannot when used by a server component) take in non-serializable props. Given "use client" is meant to mark client components to be usable by server components, turning off this warning would only cause harm and you would get the Error: Functions cannot be passed directly to Client Components unless you explicitly expose it by marking it with "use server". when trying to do something like pass a function to the client component from a server component.

@ColemanDunn no you don't get what I'm saying. If a client component is always only used by other client components, its arguments don't need to be serializable.

when trying to do something like pass a function to the client component from a server component.

Exactly. But if you have client components that are never called from other server components, because they're only called from other client components, then the warning should never appear.

For me, removing the export keyword was a solution:

'use client'

export function Foo() {
  return <Bar nonSerializable={...}/>
}

function Bar() { // remove export from the child component
  return ...
}

This rule actually makes sense:

• If you export a component, then any server component can import and use it (accidentally or not). You can't be 100% sure.
• By removing the export keyword, you tell that the component will not leave this module.

Or if you want to keep the export ("you-know-what-you're-doing"), just put the @ts-expect-error directive.

No it doesn't make sense, if you're not using it from a server component.

If you use export, you can't control who's the caller. It can be any component, including RSC.

I can because I'm the programmer. (same argument for teams)

A very strong argument (especially for teams) 🤣

Maybe for you and your teams it wouldn't be 🤔 haha

And a computer can make a graph and determine if it's being used by a server component and only then show the alert - otherwise there isn't an error.

My initial idea was about external code. Taking libraries in example, authors don’t know how and by whom their code will be called. Respectively, their computers are not able to build a graph.