Add get_str_value and split_representation Support In Phone Number Serializer Field

[keshavmohta09]

Add get_str_value and split_representation support

• get_str_value: boolean value to get string type of phone number in validated data when needed
• split_representation: boolean value to represent country code and number separately

[francoisfreitag]

Hi, thanks for submitting a PR!

Could you explain why these changes should be made?

Currently, I am thinking of rejecting both:

• get_str_value, from django REST framework docs:

  The .to_internal_value() method is called to restore a primitive datatype into its internal python representation.

  The internal Python representation of a phone number should be a PhoneNumber instance.

• to_representation, I like the fact that the representation can be fed back to the serializer. With this proposal, we would need to change to_internal_value() to handle the split representation. It seems easy to subclass PhoneNumberSerializer to add your own to_representation, if the custom implementation does not fit your use case. But I’ld like to hear about your use case :smiley:

[keshavmohta09]

Hello, thanks for viewing the changes.

I agree that the phone number instance should be returned from the to_internal_value method, but in many cases, we need its string value, so I have added a flag.

In the case of split_representation, in most cases the country code and phone number need to be sent separately to the frontend, and displayed separately, that's why I have added and we can also handle accepting the same format if needed.

[francoisfreitag]

I agree that the phone number instance should be returned from the to_internal_value method, but in many cases, we need its string value, so I have added a flag.

Why not call str() on the object returned from the serializer ?

In the case of split_representation, in most cases the country code and phone number need to be sent separately to the frontend, and displayed separately, that's why I have added and we can also handle accepting the same format if needed.

It really depends on the use case. Some projects will just use an <input type="tel">, others will have a separated <select> for the country code, and only ask for the national significant parts (see the existing widgets for alternatives). There are unofficial JS implementations for Google libphonenumbers, which allow to manipulate the phone number in the front-end, so developers can be creative. As far as this library is concerned, sending a string phone number that follows one of the supported formats seems a reasonable default to me. Projects needing their own representation can easily override to_representation(). Barring a compelling argument, I think we should stick to the current implementation.

[keshavmohta09]

Okay, thankyou for guiding me. I am closing this PR.