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

Fixes #146 #149

Merged
merged 4 commits into from Feb 26, 2021
Merged

Fixes #146 #149

merged 4 commits into from Feb 26, 2021

Conversation

gaetschwartz
Copy link
Contributor

This PR fixes #146.

As per discussed in #148 it would be better to tackle this issue first, so here is the PR.

WWhile running the tests, the google-fonts-flutter\test\load_font_if_necessary_test.dart: loadFontIfNecessary method calls http get test hangs indefinitely regardless of my fix or not. Am I doing anything wrong ?

@gaetschwartz
Copy link
Contributor Author

gaetschwartz commented Feb 24, 2021

CI is failing because of path_provider's getTemporaryDirectory being non nullable, #148 fixes it. I also had to fix it here so that the CI can run properly.

@kevmoo
Copy link
Contributor

kevmoo commented Feb 24, 2021

@clocksmith @pennzht @johnsonmh ?

if (fontData == null) return;

final fontLoader = FontLoader(familyWithVariantString);
fontLoader.addFont(byteData as Future<ByteData>);
Copy link
Contributor

Choose a reason for hiding this comment

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

Should it be like this?

  fontLoader.addFont(Future.value(fontData));

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think so. What does this get us?

Copy link
Contributor

Choose a reason for hiding this comment

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

#146 (comment)

Because addFont requires a Future<ByteData> as input, and the value is already loaded, we can simply pack it inside a Future.value and pass it in.

Copy link
Contributor

Choose a reason for hiding this comment

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

Could it take FutureOr<ByteData>? Avoiding an unnecessary wrap would be nice.

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, it seems this case isn't covered in tests, right?

Copy link
Contributor

@pennzht pennzht Feb 24, 2021

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

The current impl just reuses the existing future, right? That should be fine – instead of creating a new one.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Exactly, the current uses the existing future.

Copy link
Contributor

Choose a reason for hiding this comment

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

@gaetschwartz I think you'll need to wrap the value. So you have a Future<ByteData> instead of Future<ByteData?>

Have you tested this workflow to make sure it works? Are there tests?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I ran the examples and it worked without but I can still do if you want

@kevmoo
Copy link
Contributor

kevmoo commented Feb 24, 2021

@gaetschwartz – we have zero tests here, it appears.

have you verified that your latest bits pass?

Should we add tests? Seems like a gnarly thing to let through w/out verification

@gaetschwartz
Copy link
Contributor Author

Alright, can I make the method public with @vsisibleForTesting ? @kevmoo

@kevmoo
Copy link
Contributor

kevmoo commented Feb 24, 2021

Alright, can I make the method public with @vsisibleForTesting ? @kevmoo

Sure!

@gaetschwartz
Copy link
Contributor Author

@kevmoo After re-reading the code I don't really think we need to make a specific test as the only place where it is used is loadFontIfNecessary and this function is tested extensively. loadFontIfNecessary relies on it to load the appropriate fonts.

TLDR; I don't think we need tests, thoughts ?

@kevmoo
Copy link
Contributor

kevmoo commented Feb 25, 2021

I defer to the package owners here, I guess. Just don't want this blowing up in production!

@gaetschwartz
Copy link
Contributor Author

Understandably. Is it @pennzht ?

@pennzht
Copy link
Contributor

pennzht commented Feb 25, 2021

@johnsonmh @clocksmith

  1. Should we add tests for this scenario?
  2. If we should, should we add them in this PR?

I think we should add a test if it fails the existing version (= if it can replicate and catch the bug #146).

@gaetschwartz
Copy link
Contributor Author

gaetschwartz commented Feb 25, 2021

@pennzht I don't really know how to mock FontLoader but what I can do is call _loadFontByteData with different arguments and make sure it doesn't fail. Does it seem right to you ?

Comment on lines 281 to 301

test('loadFontByteData doesn\'t fail', () {
expect(
() async => loadFontByteData('fontFamily', Future.value(ByteData(0))),
returnsNormally,
);
expect(
() async => loadFontByteData('fontFamily', Future.value(null)),
returnsNormally,
);
expect(
() async => loadFontByteData('fontFamily', null),
returnsNormally,
);

expect(
() async => loadFontByteData('fontFamily',
Future.delayed(Duration(milliseconds: 100), () => null)),
returnsNormally,
);
});
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added this test, thoughts ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Seems reasonable to me!

@kevmoo
Copy link
Contributor

kevmoo commented Feb 25, 2021

@clocksmith – would you merge?

@pennzht
Copy link
Contributor

pennzht commented Feb 26, 2021

@gaetschwartz Thank you so much for your PR!

@kevmoo
Copy link
Contributor

kevmoo commented Feb 26, 2021

@pennzht – are you going to merge?

@clocksmith clocksmith merged commit e3f7667 into material-foundation:develop Feb 26, 2021
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.

[BUG] Unhandled Exception: type 'Future<ByteData?>' is not a subtype of type 'Future<ByteData>'
4 participants