-
Notifications
You must be signed in to change notification settings - Fork 20
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
Get rid of withAuth? #33
Comments
Hey @lorensr IMO, if you are using One authentication service, like And then comfortably bring in the |
Thanks—do you see any downsides to reusing withUser everywhere instead of
using it once at the top and prop drilling?
…On Sun, Jun 17, 2018 at 6:28 AM Prosper Otemuyiwa ***@***.***> wrote:
Hey @lorensr <https://github.com/lorensr> IMO, if you are using withAuth
once, why make it at all? The withAuth might really not need to exist.
One authentication service, like Auth.js with all the helpers needed can
do the magic. Check this Auth Service file
<https://github.com/auth0/blog/blob/master/_includes/asides/react.markdown#dependencies-and-setup>.
And tie it in with the withUser HOC
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#33 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAPVmKnVE2P2gn00mn08vMhORkDsQ1tOks5t9i80gaJpZM4Uh7y5>
.
|
No, I don't. It's just a matter of trade-offs. Do you want to prevent prop drilling because of how stressful and confusing it can be in the long run? If yes, then just use the |
Okay, here's the plan! I'm liking it a lot. Lmk if you have any further thoughts @unicodeveloper @jeresig
// withUser.js
export const USER_QUERY = gql`
query UserQuery {
currentUser {
firstName
name
username
email
photo
hasPurchased
}
loginInProcess @client
}
`
export const withUser = graphql(USER_QUERY, {
options: { fetchPolicy: 'cache-only' },
props: ({ data: { currentUser, loginInProcess, loading } }) => ({
user: currentUser,
loggingIn: loginInProcess || loading
})
}) // auth.js
const fetchUserData = () =>
apollo.query({
query: USER_QUERY,
fetchPolicy: 'network-only'
})
// fetch at pageload in case client is already logged in
fetchUserData()
export const login = () => {
apollo.writeData({ data: { loginInProcess: true } })
auth0Login({
onCompleted: e => {
apollo.writeData({ data: { loginInProcess: false } })
if (e) {
console.error(e)
return
}
apollo.reFetchObservableQueries()
fetchUserData()
}
})
}
export const logout = () => {
auth0Logout()
apollo.resetStore()
} And then in components: import { withUser } from '../lib/withUser'
import { login, logout } from '../lib/auth'
class Profile extends Component
…
export default withUser(Profile) This simplifies |
Turned out to be simpler—given deduplication and default |
Made
withAuth
to not have to mess with<App>
and give example of making HOC. Not feeling like either reason is very important.Globals?
Inspired by DHH's series on writing software well, in an episode recommending judicious use of globals, eg for the current user.
Could be used for
login
/logout
functions.So that eg in
Profile.js
you can:instead of getting them as props.
Prop drilling vs HOC vs Context/unstated
Need a reactive data source for
loading
¤tUser
, so can't do globals.Reusable query
Could do a
withUser()
HOC that provides them throughgraphql()
to any component that needs it. All using default cache-first, and deduplication should combine them into one query, while also maintainingdata.loading
/loadingUser
.loggingIn
intoloading
? In the single-usewithAuth
, it's defined as:loading={loading || this.state.loggingIn}
(or alternatively could make a reusable
<WithUser>
query component, but that takes more characters and indentation to use)Prop drilling
A single normal query at the top. Lot of drilling. It's nice for testing, but not nice to read/write. Would personally prefer to avoid.
Context/unstated
The text was updated successfully, but these errors were encountered: