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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emit warning on non-literal content inside of Trans #881

Merged
merged 4 commits into from
Aug 16, 2023

Conversation

nicegamer7
Copy link
Contributor

Why am I submitting this PR

We noticed in our project that JSX expressions were being extracted incorrectly. We noticed this by setting debug: true when initializing i18next, then seeing that expressions were extracted as empty non-self-closing tags.

Does it fix an existing ticket?

No.

Checklist

  • only relevant code is changed (make a diff before you submit the PR)
  • tests are included and pass: yarn test (see details here)
  • documentation is changed or added

@karellm
Copy link
Member

karellm commented Aug 10, 2023

@nicegamer7 It looks like a breaking change. The last test looks like it was intended to do what it does. Can you please develop a little more why the current code is broken?

@nicegamer7
Copy link
Contributor Author

@karellm Certainly, my appologies for not including this in the PR initially.

After taking a look at this a bit further, it seems I was incorrect. We can't actually extract expressions correctly, unless they're literal values. I'm going to change this to emit a warning in this case.

Here's the code sandbox where I determined this: https://codesandbox.io/s/long-water-dggns9?file=%2Fsrc%2FApp.tsx

See the debug lines in the console (or the following screenshots) for what the correct extracted value is (the keys that i18next is looking for in the resources).

image image image image

So as seen above, neither key is extracted as the expression text, but rather the value. Since we can't extract the value in this tool unless it's a literal, it makes sense to emit a warning.

@karellm
Copy link
Member

karellm commented Aug 11, 2023

I'm ok with adding the warning but don't you think that leaving the non-litteral function in the default value provides more context that making it look like it actually worked at extracting it? It is still a breaking change and I want to make sure that we are making the right decision here and not start a ping-pong between both solutions.

@nicegamer7
Copy link
Contributor Author

Okay, I think that makes sense. I revert most of this and just leave the warning.

@codecov-commenter
Copy link

codecov-commenter commented Aug 11, 2023

Codecov Report

Patch coverage: 100.00% and project coverage change: +0.01% 🎉

Comparison is base (6bd3526) 93.94% compared to head (fcce8f3) 93.95%.
Report is 11 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #881      +/-   ##
==========================================
+ Coverage   93.94%   93.95%   +0.01%     
==========================================
  Files          11       11              
  Lines        1832     1836       +4     
==========================================
+ Hits         1721     1725       +4     
  Misses        111      111              
Files Changed Coverage Δ
src/lexers/jsx-lexer.js 98.47% <100.00%> (+0.01%) ⬆️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@nicegamer7 nicegamer7 changed the title Fix extracting expressions from Trans components Emit warning on non-literal content inside of Trans Aug 14, 2023
@nicegamer7
Copy link
Contributor Author

@karellm Just wanted to bump this; take your time if you're busy, no rush.

@@ -233,10 +233,10 @@ describe('JsxLexer', () => {
it('erases tags from content', (done) => {
const Lexer = new JsxLexer()
const content =
'<Trans>a<b test={"</b>"}>c<c>z</c></b>{d}<br stuff={y}/></Trans>'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you modify theses two tests? Leaving {d} in there is more informative don't you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I suppose so. Would you like me to assert that a warning is emitted in these tests as well? Or should I just undo the changes?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I usually prefer tests that check for a single thing as they are easier to maintain but I don't have a strong opinion either way.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I tend to agree. I'll leave it out in that case.

@karellm karellm merged commit 863c43b into i18next:master Aug 16, 2023
4 checks passed
@karellm
Copy link
Member

karellm commented Aug 16, 2023

Thanks, I just published 8.6.0

@nicegamer7
Copy link
Contributor Author

Thanks karellm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants