Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

make return type of t a branded type like TranslatedString rather than plain string to aid type safety #2028

Open
WickyNilliams opened this issue Sep 6, 2023 · 7 comments
Assignees

Comments

@WickyNilliams
Copy link

馃殌 Feature Proposal

It would be useful if the t function returned a branded type, rather than a plain string, so that you can enforce at a type level that a function/component/other is receiving a translated string.

Motivation

Consider you have a function showToast which can be called from anywhere in the app to show a message to the user e.g.

function showToast(message: string) {
  // ...
}

in the ideal, all strings passed to it have been translated:

showToast(t("some.key"))

but there is nothing stopping you from doing:

showToast("oops not translated") // no type error :(

this will produce no errors, and can only be caught through ongoing diligence and manual review. as such, this is error prone.

It would be useful if the t function returned a branded type like

type TranslatedString = string & { __type: "TranslatedString" }

Example

with a branded type you can enforce via the type system that untranslated strings are not propagating through the system:

function showToast(message: TranslatedString) {
  // ...
}

showToast("oops not translated") // type error 馃帀 
@adrai
Copy link
Member

adrai commented Sep 6, 2023

isn't this already done by @jtbandes ? #1994

@WickyNilliams
Copy link
Author

I looked at that before posting, i think it's a different thing? that seems to be related to accepting the t function itself as a param, whereas i'm talking about accepting the return type of t function as a param. correct me if i'm wrong! i'd be happy if this is already available :)

@jtbandes
Copy link
Contributor

jtbandes commented Sep 6, 2023

This is a good idea, but might be an even bigger breaking change than mine was 馃槄

@WickyNilliams
Copy link
Author

WickyNilliams commented Sep 11, 2023

haha yes, very possible it would be. wondering if it could be opt-in behavior, via config or via a new t function, so that it doesn't blow up a million codebases. for existing projects this would need to be carefully managed. but for greenfield, i expect many would want this (i am in this position :))

@jtbandes
Copy link
Contributor

Yes, I鈥檓 sure you could make it opt-in via CustomTypeOptions or something like that.

Copy link

stale bot commented Dec 15, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Dec 15, 2023
@WickyNilliams
Copy link
Author

Don't close please :)

@stale stale bot removed the stale label Dec 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants