Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make i18n functions filter their return values #27966
Make i18n functions filter their return values #27966
Changes from 9 commits
f9b484a
99d3466
5176c06
1efa483
4a3c2d7
2866eb9
883bc53
a0a0a73
e955c4c
40cb141
a320295
815a422
f8eca3a
d6ae239
8ab3436
f34fcf0
f9650fe
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: type names start with a capital letter:
GetFilterDomain
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed. Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Converting the translation to always be of a string type seems a bit restrictive. Is there a reason not to allow it to be filtered into any type of value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The type definitions / JSDoc say that it returns a string, so it makes sense to uphold that promise, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be worth removing the type conversion and updating the JSDoc? I think it will make the filters a lot more flexible, especially in a React context, where it might not be uncommon to need to return a React component directly as a result of the
gettext
call.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When used in a React component:
The return value of
__()
can be a genericReactNode
, which includes many possible value types,string
being one of them.It would be nice to keep this flexibility -- there are creative use cases that benefit from it.
The return type of
hooks.applyFilters
isunknown
. If we want to coerce that into astring
, we can use a type annotation:That affects only the type checker, and doesn't do runtime conversions like
String()
does.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm more than happy to make this change (The String() calls always made me feel a little uneasy!) I've tried the annotation approach required here, but can't seem to make it compile, and unfortunately I don't know enough about the syntax to coax it into submission.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jsnajdr It looks like
applyFilters
returnsunknown
rather thanany
which means (I think) that we can't just type hint it?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting. The
unknown
type should be assignable to anything else, without constraints. I though thatvalue as string
is exactly the same thing as/** @type {string} */ value
, but TypeScript playground reports error only for the second (jsdoc) one:@sirreal Do you have any insight about what's going on? Maybe there is some TS option that affects this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@leewillis77 I found that this workaround works:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jsnajdr Thanks. PR updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EDIT This is a response to a few previous comments the thread and focuses on the types. It does not take into account the other context and is not a request for changes.
Anything can be assigned to the
unknown
type, butunknown
does not satisfy any other types.any
is the type that satisfies all other type (and anything can be assigned toany
.You can read more about
unknown
in its announcement.When we really don't have type information, especially at the boundaries of our typed application like a REST response or receiving data across untyped APIs like here,
unknown
makes that very clear and forces you to narrow with guards or type assertions. Beforeunknown
, there was onlyany
which was completely unsafe because you can put anything in and do anything with it.The error is expected and the fix is what TypeScript recommends (this is a type assertion written in JSDoc). First, we assert the
unknown
isany
, then we can narrow it to the type of our choosing becauseany
:A (safer) alternative would be to use a type guard, but has a runtime cost:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's one more thing that I thing is worth testing: interaction of the default
i18n
with the defaulthooks
:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added packages/i18n/src/test/default-i18n.js. Thanks!