Fix [object Object] in Widget Permissions

[Palid]

Due to two-step translations we could sometimes end up in a case where
instead of a string we'd get a React Node wrapper, which tried being
translated for the second time. This commit solves this problem by
verifying if we have passed both Tags and Variables.

Fixes element-hq/element-web#18384

Attaching a screenshot of current behavior with the fix:

[t3chguy]

is wrong though, it says share data with ., the widgetDomain is missing. Isn't that the entire issue here, that would cause the [Object object] explosion which you are now guarding against, but IMO the caller should guard against it

[t3chguy]

This is just masking over the issue of a missing/invalid variable, not actually fixing the issue. See #6560 (comment)

with <BLANK>.

[Palid]

This is just masking over the issue of a missing/invalid variable, not actually fixing the issue. See #6560 (comment)

with <BLANK>.

When turning off the helpIcon entirely it seems that widgetDomain in this case is just not rendering or it's empty. It's the case of Etherpad.

[t3chguy]

Just adding || ""

is enough to have the same effect as this entire PR.

Fundamentally I don't think this PR is needed. I think this issue has to be fixed per-caller, and guarded against with stricter TS, otherwise you end up with i18n output which makes no sense, so IMO its better to have something more obviously wrong e.g [Object object]

The issue here is that whatever sets widgetDomain is clearly not working in all cases, and that is what needs fixing and that resolves the object object issue.

[Palid]

Just adding || ""

is enough to have the same effect as this entire PR.

Fundamentally I don't think this PR is needed. I think this issue has to be fixed per-caller, and guarded against with stricter TS, otherwise you end up with i18n output which makes no sense, so IMO its better to have something more obviously wrong e.g [Object object]

The issue here is that whatever sets widgetDomain is clearly not working in all cases, and that is what needs fixing and that resolves the object object issue.

I dislike when you API doesn't guard you and you need to do guards yourself, but I think it's a different problem here - there was actual console warning that I haven't noticed for null being passed into the translation. I think it's a good idea to make it into a development-only error throw instead, so it's right in your face and breaks execution.

@t3chguy I'm also force-pushing a proper fix for this thing, we don't need an enormous git log as turns out that's a oneliner.

[t3chguy]

I think it's a good idea to make it into a development-only error throw instead, so it's right in your face and breaks execution.

in an ideal future, it'd be caught at build time by TS

[t3chguy]

good spot

[Palid]

I think it's a good idea to make it into a development-only error throw instead, so it's right in your face and breaks execution.

in an ideal future, it'd be caught at build time by TS

strictNullChecks anyone? 😆

[github-actions]

Here's what your changelog entry will look like:

🐛 Bug Fixes

• Fix [object Object] in Widget Permissions (#6560). Fixes Widget permissions panel says [object Object] element-hq/element-web#18384. Contributed by Palid.