-
Notifications
You must be signed in to change notification settings - Fork 116
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
Implement the onLoggedOut hook and add unit tests #196
Conversation
stevenhornung
commented
Mar 18, 2016
- Implemented the onLoggedOut hook for logout
- Updated the onLoggedIn hook to only append data.extra when a non-empty object was returned (instead of always appending data.extra)
- Added unit tests for onLoggedOut hook
- Moved onLoggedIn hook tests to same file as onLoggedOut hook tests
- Updated README for onLoggedOut hook data.extra
@kahmali let me know if you see any issues with this PR or need anything else done to get this merged. Thanks! |
I'm so sorry for the delay on this. I'm the worst. I'll get this reviewed (and hopefully merged in) tonight. |
if loginResult? | ||
_.extend(auth, extra: loginResult) | ||
extraData = self._config.onLoggedIn.call(this) | ||
if extraData and _.isObject(extraData) and (not _.isEmpty(extraData)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we requiring the extra
data be an object? A user may just want to return a string there; I won't judge :P I feel like we should try to avoid being opinionated here and just let the user return any defined value. If this was because of my unnecessary return of an empty object in the default onLoggedIn
method, I apologize for that terrible code.
Since the return value wasn't being used until very recently, and the empty object I return is more of a bug than a feature, I think it would be safe to change the default onLoggedIn
and onLoggedOut
functions to being undefined
, do an existential check here like we had before, and add another to ensure the function isn't called unless the user overrides it in the API config. Putting that together should look something like:
extraData = self._config.onLoggedIn?.call(this)
if extraData?
_.extend(response.data, {extra: extraData})
And of course my useless onLoggedIn
and onLoggedOut
functions will need to be removed from the default config in the Restivus constructor (and the docs updated to reflect that those functions are undefined by default).
What do you think of that approach?
@kahmali Exactly right. I didn't feel like always returning an empty object was the right thing to do, hence the empty obj check. I think the adjusted approach suggested is better, though. So to summarize:
Simple enough and makes sense to me. Let me know if I should just create a new PR and close this one or just push to this one with an updated commit, or ?. Thanks! |
Your summary is accurate, except one more thing: You can follow any PR strategy that's easiest to you. I personally like to rebase and force push to the same branch. It keeps the conversation all in a single thread, and doesn't create "dead end" PRs. Just my personal preference, though. There are worse things in the world than a few dead PRs. |
Here's what I'm referring to, in code form (from my code example above): extraData = self._config.onLoggedIn?.call(this) Notice my sneaky existential check of the |
Alrighty. I just pushed that change to not force data.extra to return an object. I also added that null check on the hook calls so it doesn't throw any errors after removing the function definitions from the constructor. Let me know if all this looks good! Thanks |
This looks great! I'm gonna go ahead and merge this in and publish the update. I'll let you know when it's all set. Thanks for taking care of this! |
I updated the change log and published this in v0.8.10. Thanks again for all your help with this! |