Skip to content
This repository has been archived by the owner on Oct 1, 2024. It is now read-only.

Have ExtractedLocation contain null for locales that are not available (instead of undefined) #494

Merged
merged 1 commit into from
Feb 4, 2019

Conversation

Korri
Copy link
Contributor

@Korri Korri commented Feb 1, 2019

This will allow use to serialize and keep the information as our serializer removed undefined properties.

It will remove the necessity of a hack around it on web#10270

I decided to change only the ExtractedTranslations interface as it will minimise the impact on other systems, makes for a much simpler implementation (as undefined is the return value in case of failure of a lot of methods like Map.get), and its the only place we need null.

@Korri Korri changed the title Have ExtractedLocation be returned as null Have ExtractedLocation contain null for locales that are not available (instead of undefined) Feb 1, 2019
@Korri Korri force-pushed the return-missing-async-languages-as-null branch from bc793e7 to 2a6c4ef Compare February 1, 2019 21:37
@@ -32,15 +32,15 @@ export default class Manager {
initialTranslations: ExtractedTranslations = {},
) {
for (const [id, translation] of Object.entries(initialTranslations)) {
this.translations.set(id, translation);
this.translations.set(id, translation || undefined);
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this really needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, this.translations is TranslationDictonary | undefined so null is not a valid value.

Do you think using

this.translations.set(id, translation === null ? undefined : translation);

instead be more readable?

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh right I missed that initialTranslations was an ExtractedTranslations. || undefined is fine with me 👍

Copy link
Member

Choose a reason for hiding this comment

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

I think I would rather change this so that this.translations has the same "no translation found" type as we give when you serialize it (null)

Copy link
Contributor

@nimzco nimzco left a comment

Choose a reason for hiding this comment

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

The code looks good to me, thanks for this change and the test! 👍

Copy link
Member

@lemonmade lemonmade left a comment

Choose a reason for hiding this comment

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

Just one change I think would make things a bit simpler, then LGTM 👍

@@ -32,15 +32,15 @@ export default class Manager {
initialTranslations: ExtractedTranslations = {},
) {
for (const [id, translation] of Object.entries(initialTranslations)) {
this.translations.set(id, translation);
this.translations.set(id, translation || undefined);
Copy link
Member

Choose a reason for hiding this comment

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

I think I would rather change this so that this.translations has the same "no translation found" type as we give when you serialize it (null)

@Korri
Copy link
Contributor Author

Korri commented Feb 4, 2019

Just one change I think would make things a bit simpler, then LGTM 👍

Hey @lemonmade, as I mentioned here:

I decided to change only the ExtractedTranslations interface as it will minimise the impact on other systems, makes for a much simpler implementation (as undefined is the return value in case of failure of a lot of methods like Map.get), and its the only place we need null.

I did do it that way originally, and it makes the code much more complicated (need to add a lot of || null everywhere, or some non-trivial things like changing the TranslationGetter interface to return null), so I decided against it, but if you still thinks its best I'm ok to do it.

@lemonmade
Copy link
Member

I don't think any public API needs to change, just how we store them internally. You might have to update where we store them to do || null but I think it makes it conceptually simpler.

@Korri Korri force-pushed the return-missing-async-languages-as-null branch 2 times, most recently from 337cb0a to e330349 Compare February 4, 2019 20:24
This will allow us to serialize the data and keep the information as our serializer removes undefined properties.
@Korri Korri force-pushed the return-missing-async-languages-as-null branch from e330349 to bbb9d04 Compare February 4, 2019 20:25
@Korri Korri merged commit 6d41348 into master Feb 4, 2019
@Korri Korri deleted the return-missing-async-languages-as-null branch February 4, 2019 20:45
@Korri Korri restored the return-missing-async-languages-as-null branch February 4, 2019 20:46
@Korri Korri deleted the return-missing-async-languages-as-null branch February 4, 2019 20:46
@lemonmade lemonmade temporarily deployed to production February 6, 2019 21:01 Inactive
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants