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
ref: Hub passes the Scope #114
ref: Hub passes the Scope #114
Changes from 3 commits
8c6727d
7570846
c1033b2
c3f453a
a46e144
8a14620
4c3f323
35e3072
30fa7a9
9088c88
e93f85e
7b05b0b
1f70e4f
1f4bb44
d4334a9
d02947f
ba721bd
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.
@rxlabz I noticed that all the methods are sync now because of
await
should we aim for sync calls or keep it async?
@bruno-garcia
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.
While we send the envelope to the client/transport to be sent to the network directly, this should be async.
We could make it sync if we, inside the client, pass the envelope to an Isolate. And there we could use async to send it to the network or write to disk.
I'd propose we stick to async for now, user code already expects do await on capture methods, and allows us to interface with the native layer by purely writing an envelope to disk (which is async)
if you're not using
async/await
on the method body, just remove the keywords andreturn futureObj;
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 sure I understand. They are not sync, they return a Future
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.
@rxlabz
item.client.captureEvent
returns a future, but you call this method usingawait
if you use the
await
keyboard, means you the future to be completed, so its a sync call, not async.or I am not understanding the
await
keyword in Dart, which is also possibleThere 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.
await
is just a "syntactic sugar", it doesn't change the nature of the code. Maybe https://dart.dev/codelabs/async-await will be clearer than me.But I noticed that this method is asynchronous when it calls item.client.captureEvent and synchronous if the hub is not enabled or if the event is null, we probably should change the signature to
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.
not a big fan because of:
but I got it I guess:
await item.client.captureEvent
makes a sync call, but the signature of the methodhub.captureEvent
is alsoasync
so it's fine.let's keep as it is till we have a concrete implementation of the transport layer, so we'd know what looks better.
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.
IDE does the imports like this but feels weird, whats the proper way?
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.
the linter should be pointing us to the right way (
flutter analyze
). I believe this is the way to go but I can't recall nowThere 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.
it didnt complain, thats why
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.
Normally in Dart, relative imports should be preferred https://fuchsia.dev/fuchsia-src/development/languages/dart/style#do_import_all_files_within_a_package_using_relative_paths
( but I know that the Flutter team doesn't follow all the Dart styleguide :) )
In IntelliJ, the autocompletion often shows both the relative and
package:
imports. I don't know if VSCode can be configured is this way.We could also activate this lint https://dart-lang.github.io/linter/lints/prefer_relative_imports.html which seems to not be activated with
pedantic
to enforce the rule.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.
nice I created a task for it