@mel i've used everything, but react router v4

@drk do you happen to have an example you can share. The graph.cool example isn’t optimal 😕

my project isn't open (yet), but i can link an example repo that has some solid practices

Well it’s a little tough to keep everything in a functional paradigm since

auth0-lock

isn’t very reacty

oh yeah for sure that example as a good wrapper component for lock

Great! Just found that. The only issue being that

react-router

v4 strongly discourages imperative routing logic...

@drk do you happen to have an example you can share. The graph.cool example isn’t optimal 😕

can you go into more detail? Happy for suggestions, issues, PRs :P

@nilan added 2 issues just now. also while running the example running into

setState(...): Cannot update during an existing state transition

every now and then

ah yea saw that thanks

@nilan If I get it working well with

react-router

v4 would you want that as a PR?

my main confusion is around gracefully handling auth0 / graphcool create / graphcool sign in, all while being transparent to the user outside of the auth0 authentication

honestly I'm not sure about v4 I did not check it out yet

@vinspee I think the key is a little bit of callback hell 😈

this._lock.on('authenticated', authResult => {
      localStorage.setItem('id_token', authResult.idToken)

      this._lock.getUserInfo(authResult.accessToken, (err, profile) => {
        if (err) {
          // TODO: alert
        }

        console.log(profile);
        this.props.createUser({
          variables: {
            idToken: authResult.idToken,
            familyName: profile.family_name,
            givenName: profile.given_name,
            email: profile.email,
            picture: profile.picture
          }
        })
          .then(() => {
            this.props.history.push('/community')
          })
          .catch(err => {
            // TODO: alert
          })
      })
    })

i’d like to keep the logic out of the component, so I think i’ll have to pass the mutation function as a parameter to the

onClick

of the auth0 login button

@mel in your error catch, you can check if the error tells you that the user already exists - in this case you can set the token to your local storage

@nilan ah yes! that could work. let me give it a shot

it does all feel a bit messy

I see @mel. @vinspee I agree that the way I set up the example is not optimal. I think in a real app you would want to factor out the auth logic/states in a separate component. maybe even combine it with a state management system like Redux

exactly

what do you mean?

i mean trying to figure out where i am in the auth flow

🙏 this is great. thank you @vinspee and @tom

@mel @vinspee I think some tweaks are needed to make that example I have work. I'll try to find some time to update (knowing now that people are looking at it 🙂 ), but if you work it out feel free to PR.

Nice! Thanks.

that's awesome, thank you all for the effort 🙂

@tom thanks so much! 2 questions. 1. Is the signinUser mutation necessary? https://github.com/thomaswright/graphcool-auth0-apollo-auth-example/blob/master/src/AuthRouter.js#L179 Isn’t having the token header enough? @nilan it doesn’t look like you included this mutation in the auth0 write up. 2. You’re tracking two tokens a graphcool token and an auth0 token. I think when using the auth0 integration that should be the only one necessary? Correct me if I’m wrong.

@mel graphcool used to use a different token for their authentication than auth0 - they may now be the same (I haven't checked). If so, then yes, you shouldn't need the signinUser mutation or two token tracking.

Yea we now use Auth0 token for creation and authentication, so

signinUser

is not needed for the Auth0 integration anymore