Skip to content
This repository was archived by the owner on Feb 22, 2023. It is now read-only.

Conversation

@ditman
Copy link
Owner

@ditman ditman commented Oct 23, 2019

Description

This WIP PR shows the code for a web implementation of the google_sign_in plugin, that uses the JS API behind the scenes.

Things that need to be done:

  • Decide if we want to go with this, or package:googleapis
  • Ensure all method channel methods are implemented
  • Refactor method channels to the new platform interface approach.
  • Tests

Note that this is based against this so it doesn't show a ton of uninteresting file moves.

This is just a RFC from the team, and not intended to be merged as is.

@ditman ditman closed this Oct 23, 2019
@ditman
Copy link
Owner Author

ditman commented Oct 23, 2019

(No danger on this being open, since it's a PR against my own repo)

@ditman ditman reopened this Oct 23, 2019
@ditman ditman changed the title [PR] Google sign in web [WIP] Google sign in web Oct 24, 2019

import 'package:flutter/services.dart';
import 'package:flutter_web_plugins/flutter_web_plugins.dart';
import 'package:google_sign_in_web/src/gapi.dart';

Choose a reason for hiding this comment

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

nit: prefer to use relative imports for same-package imports (i.e. import 'src/gapi.dart';)

Copy link
Owner Author

Choose a reason for hiding this comment

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

I'll change this, but I don't know enough dart to have been bitten by any issue with package vs relative imports. Any reason for this?

I did this because I think I remember reading somewhere in the dart docs something along the lines "always prefer import from package:blah, because it always works" or similar :/

// Initialize the gapi
return _init(call.arguments);
case 'init': // void
return _init(call.arguments)

Choose a reason for hiding this comment

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

you should be able to just return null

Copy link
Owner Author

Choose a reason for hiding this comment

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

I think returning null breaks this logic, but that's what the java implementation is doing, ssssoooo null it is!

Choose a reason for hiding this comment

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

Hmm I think you're right about breaking that null-check logic. Maybe return true or something? Just wary of the toString() call just to return a signal that the initialization was successful

Copy link
Owner Author

Choose a reason for hiding this comment

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

I like return true, I'll get that done. .toString rubs me the wrong way too.

However, the Java implementation returns a success-with-null; I guess null is being handled differently, OR the plugin itself makes sure not to call init multiple times.

@harryterkelsen
Copy link

Also consider migrating to the new "platform interface" way, so you can have a more type-safe and tree-shakeable API

@ditman
Copy link
Owner Author

ditman commented Oct 25, 2019

Also consider migrating to the new "platform interface" way, so you can have a more type-safe and tree-shakeable API

Yep, in fact I'm going to do that first, then rebase this branch with the platform interface-d plugin, and write the web version using that.

@harryterkelsen
Copy link

Sounds good, but bear in mind that you have to submit the platform interface change in a separate PR so that this change can depend on it without a path dependency.

@ditman
Copy link
Owner Author

ditman commented Oct 25, 2019

Sounds good, but bear in mind that you have to submit the platform interface change in a separate PR so that this change can depend on it without a path dependency.

Yes, that's the plan, submit the platform interface first in a separate place, then rebase this against the new master and move things around here.

@ditman
Copy link
Owner Author

ditman commented Oct 29, 2019

@hterkelsen I added the platform interface and other goodies here:

#96

I'll start prepping each package for individual release, with more relevant PRs shortly.

@ditman
Copy link
Owner Author

ditman commented Oct 31, 2019

(Moving these PRs to a more "final" set)

@ditman ditman closed this Oct 31, 2019
@ditman ditman deleted the google_sign_in_web branch November 15, 2019 02:37
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.

3 participants