What I'm looking forward to in the very first iteration is simplicity similar to what <input type="file" /> provides in web. Upload flow and storage management would be delegated to the controller (which is up to user to implement according to the provided interface)

Understandable, and on second thought I can see what I had in mind rather being a self-contained UI package that just has bindings to firebase or anything else. I'll look into it if I ever get the time.

Super excited you're working on these btw !

feel free to check out @invertase/ui branch

1. we're planning to build drop-in widgets for firestore/rtdb, but auth is a higher pirority for now
2. this is something we could consider
3. Localization work is in progress. We want the library to be locale-friendly (providing a default set of languages as well as ability to override those)

1. currently phone picker sets a country based on device locale, giving an option to override it is definitely a nice thing to have, noted 👍
2. Error handling is yet to be improved. We'll provide a set of default error messages (localized) together with ErrorText widget (which will take care of finding the right label depending on error code)

An option to set only one country would be also a required feature of such ui widget. For example, app developed only for 1 specific country users.

Also, more generally, it'd be really cool if Firebase UI offered a FirebaseImageProvider that took a storage location and handled cache and all that.

+1

I just tried and the Apple sign in button still does not appear for Android or Web when using SignInScreen widget. Works fine on iOS. I guess if there's a problem blocking Android I understand why it's not working there yet, but does Web have the same problem?

It seems likely that users have both an iPhone and a computer and may like to sign in on both. Probably less likely to have both iPhone and Android.

@jpangburn Have you received any news on this? I believe Apple Sign In button is working now for web, but do you know if it is working for Android?

I guess there are a ton of different things you could eventually do with the table but from my first attempt at using it, I'd mainly like to see:

• Custom Widget rendering inside each table cell
• Custom onTap methods for each cell
• Conditional coloring/highlighting based on developer-set logic

I think I can build a table that does this with the FirestoreListView but it won't have the same pagination UI as the FirestoreDataTable

cc @rrousselGit

Try dart pub global run flutterfire configure. The error you got is because the folder pub saves packages to isn't on your system's PATH, so you can either google how to change that for your computer, but that command should bypass the issue.

Thank you for pointing me in the right direction. dart pub global run flutterfire configure gave "No active package flutterfire." in the terminal.
The solution was to run export PATH="$PATH":"$HOME/.pub-cache/bin" and then dart pub global activate flutterfire_cli and finally flutterfire configure worked fine.

It's been a year for this request. Any update to add email link sign-in to web?

@Aiiboo the issue with an email was fixed in #7772

As for successful registration callback, you could either listen to the FirebaseAuth.instance.authStateChanges() as mentioned here or provide actions as described here

SignInScreen(
  actions: [
    AuthStateChangeAction<SignedIn>((context, _) {
      Navigator.of(context).pushReplacementNamed('/profile');
    }),
  ],
  // ...
)

A lot of examples are needed on this for real as it is too abstract?

abstract class EmailFlowController extends AuthController {
  void setEmailAndPassword(String email, String password);
  Future<void> verifyEmail([ActionCodeSettings? actionCodeSettings]);
}

In EmailFlowController, there is only two methods in abstract lever so we are able to use only two methods.

I am trying this

controller.setEmailAndPassword(
  model.email ?? '',
  model.password ?? '',
);

still currentUser is getting null.

Should we make setEmailAndPassword method async @lesnitsky ?

Solved the issue by passing action to AuthFlowBuilder.

https://github.com/firebase/flutterfire/tree/master/packages/firebase_ui_auth

https://github.com/firebase/flutterfire/tree/master/packages

Do you mean to allow someone to sign in using their display name? Display name isn't unique.

Thanks for the reply.

Currently using firebase_auth_ui and the SignInScreen with EmailAuthProvider. When a user registers it only offers a email, password, confirm password. There is a option to add a display name field for registration on Firebase Auth Web, so I would like to see if there is a way of enabling this to new registrations in flutter.

I use display names in the app and want to capture this at registration rather than a manual add afterwards in Profile Screen.

In the documentation here
https://github.com/firebase/flutterfire/blob/master/packages/firebase_ui_auth/doc/providers/email.md
you can see the suggested method is to write your own LoginView - which would mostly be just copy the existing LoginView, and call LoginView from your own code - as shown in the docs. In your LoginView.dart you can modify the build method to add "display name" before or after EmailForm. Use action == AuthAction.signUp to check if registering or logging in.
Some other possibilities are to modify the shipped login_view.dart and remember to redo your mod every time you do a pub update. Another possibility is to capture the email address and display name before calling SignInScreen - then pass the email address to the SignInScreen constructor and it won't ask for the email address.

Correction, it is the first setState call in the _finishEditing function that goes wrong - the debug console indicated it was the second - maybe it's both. Anyway, why is the _finishEditing function being called when the profile screen opens ??????? From looking in the code it is called in four places, two from button press and two from field submission - so it shouldn't be called at all when the profile screen first opens.

I set a breakpoint on the first call to setState in _finishEditing and it shows the _finishEditing call is coming from the onSubmitted callback for the TextField in editable_user_display_name line 130.

This is coming from editable_text.dart line 2773 in the _finalizeEditing function

which is called from the connectionClosed function line 3013

Why does it think it has to finalize editing when the profile screen opens after signing in?

Stack:
_finishEditing (editable_user_display_name.dart:54)
_finishEditing (editable_user_display_name.dart:50)
(editable_user_display_name.dart:130)
_finalizeEditing (editable_text.dart:2773)
connectionClosed (editable_text.dart:3018)
_handleTextInputInvocation (text_input.dart:1892)
_handleTextInputInvocation (text_input.dart:1768)
_loudlyHandleTextInputInvocation (text_input.dart:1753)
_loudlyHandleTextInputInvocation (text_input.dart:1751)
_handleAsMethodCall (platform_channel.dart:555)
_handleAsMethodCall (platform_channel.dart:552)
(platform_channel.dart:548)
(binding.dart:393)
(binding.dart:390)
send (binding.dart:370)
_invokeMethod (platform_channel.dart:308)
_invokeMethod (platform_channel.dart:302)
_invokeMethod (platform_channel.dart:586)
invokeMethod (platform_channel.dart:585)
invokeMethod (platform_channel.dart:584)
finishAutofillContext (text_input.dart:2357)
finishAutofillContext (text_input.dart:2091)
dispose (autofill.dart:240)
unmount (framework.dart:5179)
_unmount (framework.dart:1960)

I reported this on github
https://github.com/firebase/flutterfire/issues/11070

@graemep-nz I think the basic decision to make is whether you will merge all changes from v1.4.4 or not, for example you might choose to work on UI aspect of the package, then I think it is normal pull of change from upstream repo and choose which change to merge.

Hey do you have any updates? Did you manage to get the fork to work with customizations?

No, I decided not to fork it, so far. I will have another look at it in a few weeks.

Ok interesting. What are you using as alternative?

I'm still using it but I have a lot of other stuff to do on my app first, then I'll see if I still want to customize it. In case you haven't seen it, there's a little bit of info in the docs on how to customize e.g.
https://github.com/firebase/FirebaseUI-Flutter/blob/main/docs/firebase-ui-auth/providers/email.md

FirestoreQueryBuilder to the rescue: https://pub.dev/documentation/flutterfire_ui/latest/firestore/FirestoreQueryBuilder-class.html

Yeap. I ended up using FirestoreQueryBuilder. Thanks for answering my inquiry.