Post user to API #81
Post user to API #81
Conversation
| @@ -51,18 +56,31 @@ export const actions = { | |||
| if (authResult && authResult.accessToken && authResult.idToken) { | |||
| try { | |||
| const decodedIdToken = jwtDecode(authResult.idToken); | |||
| // TODO - alter API singleton so it auto-syncs to redux state / local storage | |||
There was a problem hiding this comment.
Have you made an issue for this?
There was a problem hiding this comment.
Gooood idea #95
| @@ -0,0 +1,3 @@ | |||
| import BarTopAPI from '../apis/bartop'; | |||
There was a problem hiding this comment.
Out of curiosity, why even add this layer? Why not import from the apis/ folder directly?
There was a problem hiding this comment.
Hmm, so the apis folder is declaring the API classes, but these singletons are the actual instantiations. I thought the distinction between the class & the instance was nice. But there very well may be a better way to handle / organize singletons in JS, I'll look into it
There was a problem hiding this comment.
I see what you're saying. I think that's fine, I hadn't really thought about it like that and it seemed like it may be overkill. But if that's helping your organization, looks good to me.
| @@ -77,9 +95,7 @@ export const actions = { | |||
| } else if (err) { | |||
| errorOut(err); | |||
There was a problem hiding this comment.
What does errorOut() do? Couldn't find documentation for it at first glance
There was a problem hiding this comment.
just some shorthand, check out line 47 above it:
// shorthand for when we encounter an error during this authentication process
const errorOut = err => {
console.error(err);
dispatch(actions.loginFailure(err));
// TODO - go somewhere for failure or unauthenticated jawns
history.replace('/');
};There was a problem hiding this comment.
Oh I forgot that I'm a huge idiot haha carry on
| @@ -0,0 +1,24 @@ | |||
| import { errors } from '../strings'; | |||
|
|
|||
| export default class API { | |||
| @@ -0,0 +1,3 @@ | |||
| import BarTopAPI from '../apis/bartop'; | |||
There was a problem hiding this comment.
I see what you're saying. I think that's fine, I hadn't really thought about it like that and it seemed like it may be overkill. But if that's helping your organization, looks good to me.
Our first API call 👶
This PR includes some overhead to stay DRY and future-proof for all those other API jawns we'll be doing at some point. It has:
a Redux middleware that allows you dispatch a particular type of "Call API" action. This middleware snags these actions and automatically dispatches the corresponding
REQUEST,SUCCESS, andFAILUREactions per the response from the callan inheritance based system for defining APIs. There is a base API class that constructs with a URL and has a generic
callmethod. For any API that we want to use (just our BarTop API for now, but v soon the Auth0 API), we inherit this class, construct it w/ the proper URL, and add methods that correspond to endpoints. So there's acreateUsermethod in theBarTopAPIwhich will perform thePOST, etc. Behind the scenes, these methods are just calling the BaseAPIcallmethod w/ differentendpointsandinitoptions (like POSTS, headers, etc)adjustments to our authentication flow to call the
POSTwhen we detect that it is the user's first login