Support for SSR

[monolithed]

It would be great to separate the formatting functions so they can be reused in the SSR code.

[ArtyomVancyan]

@monolithed, please be more specific. What is that you want to do, and you're unable to do it, or is the limited functionality preventing you from doing it?

[monolithed]

@ArtyomVancyan, first, I format the data on the client side to display it to the user. Then I send the raw data to the server to generate a PDF file. I keep the phone numbers unformatted because they come from different sources.

As far as I can tell, the formatting functions can be moved to a separate file so they can be reused outside. Besides, with the current setup, SSR wouldn't work either.

[ArtyomVancyan]

The functions can be reused outside the hooks (I am not sure what you mean by outside). The SSR compatibility was implemented back in #30 and is used by many users as a second dependency in antd-phone-input and mui-phone-input packages.

I know none of these answers your question, and that is because I don't know its context. Please include code examples and be more specific about the issues. (e.g. here is the code I tried to do this the following way... but I got this unexpected error)

[monolithed]

The functions can be reused outside the hooks (I am not sure what you mean by outside). The SSR compatibility was implemented back in #30

The "use client" directive allows a component to be rendered only in the client environment. So if I need to display a phone number in a server component, that won’t work.
As I mentioned earlier, I’m generating a PDF file that may include phone numbers received from the client, as well as others (e.g., corporate numbers). To maintain consistency, I need a unified phone number formatting style.
That’s why I suggested applying the Separation of Concerns (SoC) principle by decoupling the formatting logic from the presentation layer.

[ArtyomVancyan]

Okay, I see. But this package is designed for React applications, which assumes the code will be evaluated on the client side (I mean, eventually). So, if you're only interested in the formatting functions and aren't using the hooks, I suggest just copying the necessary functions from index.ts to your project as additional utils.

Why don't I consider changing the "use client"? Well, I cannot change the package directive just for a specific use case, because it will break the behavior of dependent packages.

[monolithed]

I wouldn't call this use case specific. What happens after the data is transformed? It gets sent to the server to be displayed in another interface — this could be an email, a PDF, or any other interface, including web. So what's the point of a component if its data transformation logic is hardcoded for a single use case? Even if we're using React, the data entered through this component can't be rendered in the same format by another server-side React component — for example, as a default value or a placeholder. And that can happen even within a single application.
Anyway, I ended up solving my issue using react-input.