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
Add getFragment method to ReactLocalization #595
Add getFragment method to ReactLocalization #595
Changes from 3 commits
04bb1a0
cdf5ea9
695874d
435a08b
29be3dd
ab17fdb
a9b73ca
87c73d4
515918e
6027f43
f2b728c
998e786
b950f1c
59671cc
71dfc62
dc130a5
dbfbdb5
8362f23
dcf65c3
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 not really sure about this. In
<Localized/>
passing each of these in as props makes sense, but here it feels like we're putting different things into the same basket -- esp. as this is so close to the shape of thegetString()
args
argument.My first instinct would be to separate
vars
from the other two, but maybe calling this something other thanargs
could also help?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.
Oh heh, good eye. I'd actually argue that renaming
getString
s second argument tovars
would be more appropriate, since the Fluent docs also call them variables, but I can understand that changing the name of an existing API might not be desirable.I could name it something like
props
? Because they're basically analogous to<Localized>
's props, although it could also be confusing, given that they're not React props. Or how aboutparams
?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 ok with changing the internal name of the
getSrting()
argument tovars
, because it only impacts the documentation.props
andparams
aren't really better, and both come with their own sets of baggage.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.
f2b728c
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 would really rather prefer requiring
componentToRender
to be a valid element when using this method. For<Localized/>
we do need to continue supporting use with no child, but would it be possible to check for that and handle it there, rather than needing to do so here?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.
Hmm, I'm not sure what the best way to do that is - there'd be quite a bit of duplication in initialising the bundle and handling its various error cases. Personally I wouldn't be too worried about doing too much error handling. What I could do is update the type definition of
getElement
to only allowReactChild | ReactFragment
? Then we're technically requiring it to be a valid element in the public API.Or, hmm, what I could also do is update
<Localized>
to check for non-element children and, if found, wrap them in a fragment and pass that togetElement
? That would cause the latter to do some unnecessary work, but nothing too egregious I thinkg - what do you think?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.
How about calling
getString()
rather thangetElement()
from a Localized with non-element children, and wrapping the result in a Fragment? As far as I can tell, that should replicate the current behaviour.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.
Ah yeah, that's clever: 59671cc
I should note that that does change the behaviour a little bit: if you do not provide a child, it will now render the string ID, rather than
null
. Which makes sense to me and aligns it with the existing behaviour ofgetString()
, but I can also imagine that that's not desirable.One way to work around that might be to set the fallback string to some unique string, and return
null
instead of a fragment ifgetString
returns the fallback string, but that feels pretty hacky :/ Alternatively, although still a change in behaviour but closer to the previous behaviour, would be to set the fallback string to the empty string, resulting in it returning a fragment containing an empty string instead ofnull
. That's technically different from what it used to be, but should have the same result for the user.