Skip to content

Conversation

@ditman
Copy link
Contributor

@ditman ditman commented Dec 6, 2019

Description

WIP the platform interface + native plugin changes for cloud_firestore federation.

Many things missing, chief of which are:

  • Finish the actual code:
    • Migration of the Document Reference Snapshots to a Stream + map on the plugin.
    • Add types for some interesting return values (like Queries, and Document References)
  • Verify that the plugin still works as intended on the emu.
  • Many tests

@ditman
Copy link
Contributor Author

ditman commented Dec 6, 2019

(Force-pushed after rebasing with the latest master)

@collinjackson collinjackson self-requested a review December 6, 2019 01:54
…napshots'

This is to prevent naming collisions with the same method from Document
References.
Copy link
Contributor

@collinjackson collinjackson left a comment

Choose a reason for hiding this comment

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

I have one high level concern about how we're structuring the platform interface (see below) and some style nits that apply throughout this PR:

https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#use-a-trailing-comma-for-arguments-parameters-and-list-items-but-only-if-they-each-have-their-own-line

Use a trailing comma for arguments, parameters, and list items, but only if they each have their own line.

Example:

List<int> myList = [
  1,
  2,
];
myList = <int>[3, 4];

foo1(
  bar,
  baz,
);
foo2(bar, baz);

https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#consider-using--for-short-functions-and-methods

Only use => when everything, including the function declaration, fits on a single line.

@@ -0,0 +1 @@
{"_info":"// This is a generated file; do not edit or check into version control.","dependencyGraph":[{"name":"cloud_firestore","dependencies":["firebase_core"]},{"name":"firebase_core","dependencies":[]}]} No newline at end of file
Copy link
Contributor

Choose a reason for hiding this comment

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

Should not be checked in to version control

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 have no idea where this is coming from; I'll remove it from the PR, and add it to .gitignore

/// You can get an instance by calling [Firestore.instance].
class Firestore {
Firestore({FirebaseApp app}) : app = app ?? FirebaseApp.instance {
if (_initialized) return;
Copy link
Contributor

Choose a reason for hiding this comment

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

This can be removed now.

TestWidgetsFlutterBinding.ensureInitialized();

group('$MethodChannelCloudFirestore', () {
final MethodChannelCloudFirestore channelPlatform =
Copy link
Contributor

Choose a reason for hiding this comment

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

Lots more to write here :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed 😭

}

// Document Reference
Future<void> setDocumentReferenceData(
Copy link
Contributor

@collinjackson collinjackson Dec 7, 2019

Choose a reason for hiding this comment

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

@amirh Does this seem right to you as a style convention for federated plugins that are wrapping instances of native classes other than the main class of the plugin?

Right now we're shoehorning everything onto CloudFirestorePlatform instead of having a PlatformDocumentReference that has the same extends-only semantics as CloudFirestorePlatform.

If we were ok with being less idiomatically Dart we could call it something like DocumentReference_setData... not sure that's actually better but I just want to make sure that we're ok with the pattern being established here.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it's definitely makes sense for the platform interface to be composed from multiple classes. In fact we've already done this in the webview plugin (WebViewPlatform and WebViewPlatformController). I think it's less of a convention thing and more of a "whatever design works fits better for a given plugin".

For this case, after discussing with Collin, it seems like multiple classes is a better choice.

@collinjackson collinjackson self-requested a review December 9, 2019 21:16
Copy link
Contributor

@collinjackson collinjackson left a comment

Choose a reason for hiding this comment

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

Per @amirh's comment, let's split PlatformDocumentReference, PlatformWriteBatch, etc. into their own classes.

@ditman
Copy link
Contributor Author

ditman commented Dec 9, 2019

Per @amirh's comment, let's split PlatformDocumentReference, PlatformWriteBatch, etc. into their own classes.

Yep, I'll try to get this refactored.


void _handleDocumentSnapshot(MethodCall call) {
final int handle = call.arguments['handle'];
_queryObservers[handle].add(call.arguments);

Choose a reason for hiding this comment

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

_queryObservers should be _documentObservers, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep, good catch!

);
}

static final Map<int, StreamController<int>> _documentObservers =

Choose a reason for hiding this comment

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

Map should be Map<int, StreamController<dynamic>>

);
}

static final Map<int, StreamController<int>> _queryObservers =

Choose a reason for hiding this comment

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

Map should be Map<int, StreamController<dynamic>>

@ditman
Copy link
Contributor Author

ditman commented Dec 11, 2019

(I'm going to close this, so no more effort is wasted here. Apologies @andrea689, I'll keep your reviews in mind in my next iteration of this! And thanks again!)

@ditman ditman closed this Dec 11, 2019
@firebase firebase locked and limited conversation to collaborators Aug 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants