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

fix: take into account user lang in Time component #1793

Merged
merged 8 commits into from Jan 14, 2021
Merged

fix: take into account user lang in Time component #1793

merged 8 commits into from Jan 14, 2021

Conversation

rubenmoya
Copy link
Contributor

@rubenmoya rubenmoya commented Jan 10, 2021

Closes #1728

This PR takes into account the user selected language to format the time in the Time component. It uses the changes done in the functional-time branch.

Also, I've added Tom as a Co-Author, since he was the one who transformed it into a functional component.

I moved the logic to a method outside the component, I wasn't sure if you prefer it on top of the comment or at the bottom, or even if you just prefer to have that logic inside the component, so any feedback is welcome.

I haven't tested it in a public page, since I'm not sure how to do it, how do I find a public page to test it? I've tried by publishing and sharing a document but I didn't see any dates.

image

Co-authored-by: tommoor <tom.moor@gmail.com>
@CLAassistant
Copy link

CLAassistant commented Jan 10, 2021

CLA assistant check
All committers have signed the CLA.

@auto-assign auto-assign bot requested a review from tommoor January 10, 2021 13:44
Copy link
Member

@tommoor tommoor left a comment

Choose a reason for hiding this comment

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

Thanks for taking this on!

Comment on lines 72 to 79
function getLocaleForUser(user) {
if (!user) {
return undefined;
}

const userLanguage = user.language.split("_")[0];
return require(`date-fns/locale/${userLanguage}`);
}
Copy link
Member

Choose a reason for hiding this comment

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

I moved the logic to a method outside the component, I wasn't sure if you prefer it on top of the comment or at the bottom, or even if you just prefer to have that logic inside the component, so any feedback is welcome.

How about we pull this out to hooks/useUserLocale ?

app/components/Time.js Outdated Show resolved Hide resolved
@rubenmoya
Copy link
Contributor Author

Tests are failing because of the snapshots related to the users api and user presenter tests, if we hardcode en_US to the presenter we'd make sure the snapshots are the same, using the DEFAULT_LANGUAGE env var it could end up being undefined (which is breaking the tests in CI) I ended up keeping en_US after the check of DEFAULT_LANGUAGE just in case. What do you think?

@tommoor
Copy link
Member

tommoor commented Jan 11, 2021

Sounds good 👌

@tommoor
Copy link
Member

tommoor commented Jan 12, 2021

Functionally this is good, but looking at the bundle size audit the require isn't working how we might have expected – all of the translations are getting included in an existing chunk because the require isn't async, causing a 3.5% increase to bundle size.

https://app.relative-ci.com/projects/TMqufq6bi8qzsOjEHSWY/jobs/545-8eb133a6-a48b-486e-84d7-8756f2013c21/modules

In order to have the translations dynamically load we probably need to make these changes unless you have another idea:

  • Create a new component, call it LocaleTime
  • Import only the languages we support into LocaleTime using a regular import, we might be able to use the values from here: https://github.com/outline/outline/blob/develop/shared/i18n/index.js#L43 or it might be copy/paste.
  • In Time we use React Suspense to load LocaleTime as it's own chunk, and have the fallback be English during loading

Does this make sense?

@rubenmoya
Copy link
Contributor Author

Yes, it makes a lot of sense, what I'm not sure about is what to move exactly to the LocaleTime component, at first I thought about the time element, but now I realised that we should also translate the tooltip, since it will show the months in english otherwise.

I've never used Suspense before, so let me get this right, should we keep what we had before as the fallback, and create a new component which also has the tooltip and the time?

Example:

<React.Suspense fallback={
  <Tooltip ... >
    <time  ... />
  </Tooltip>
}>
    <LocaleTime />
</React.Suspense>

@tommoor
Copy link
Member

tommoor commented Jan 12, 2021

should we keep what we had before as the fallback, and create a new component which also has the tooltip and the time?

I'd be happy if the fallback was a dumb html <time> tag in English with no interval-based updating, that should prevent any sort of UI flashing in most usecases and keep the <Time> component really simple, it's really just a suspense wrapper around LocaleTime then.

@rubenmoya
Copy link
Contributor Author

rubenmoya commented Jan 12, 2021

Hmm, I'm not sure what I've done wrong, but it still shows +3.74% 😅

Update: It looks like it still adds all the locales... maybe it's related to the dynamic require?

@rubenmoya
Copy link
Contributor Author

Yeah that looks better, 0.49%, I'm not sure if there is a better way to load them, I don't really like loading them manually, it's pretty easy to add a new language to shared/i18n and forget to add it in this component, it won't break, but it won't be translated...

Another thing I don't like either is how it flahes from the fallback to the LocaleTime, but I'm not sure what else we can do...

Let me know what you think!

Copy link
Member

@tommoor tommoor left a comment

Choose a reason for hiding this comment

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

Another thing I don't like either is how it flahes from the fallback to the LocaleTime, but I'm not sure what else we can do...

I think this will be better in production where the chunks are cached by the browser.

app/components/Time.js Outdated Show resolved Hide resolved
app/components/LocaleTime.js Show resolved Hide resolved
rubenmoya and others added 2 commits January 13, 2021 09:06
Co-authored-by: Tom Moor <tom.moor@gmail.com>
Copy link
Member

@tommoor tommoor left a comment

Choose a reason for hiding this comment

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

Great! Thank you.

@tommoor tommoor merged commit 93ac989 into outline:develop Jan 14, 2021
@rubenmoya rubenmoya deleted the fix/issue-1728 branch January 14, 2021 17:36
@rubenmoya
Copy link
Contributor Author

It took a while but we got there! 🚀

Let's hope it doesn't come back to bite us, locales are never easy 😅

@tommoor
Copy link
Member

tommoor commented Jan 15, 2021

Absolutely, thanks for your help

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.

Update relative timestamps to account for i18n
3 participants