Ah great, thanks! It would be great to see a larger example on your site to see how this all ties together. For example, I don't really understand what's stopping anyone from opening dev console and just calling my 'onlogin' callback and passing it fake data to impersonate another user. It seems to me that somewhere I'd still need to verify the user data with the provider.
I fully realize that that's probably due to my own ignorance and no knock on you. However, maybe there's others like me who'd benefit from some more examples.
For sure! There are some larger examples coming so that people can see it plugged into a more real-world application.
RE: onlogin, that method accepts a callback handler that is added to an internal/private array of callbacks to run once the `popup` or `redirect` sequence has finalized. It's the only externally-facing "doorway" into the OAuth flow. Everything else is inciting action (`popup()` and `redirect()`) or a read-out of the last-known payload (`last()`). It's actually very similar to a state manager I wrote a while back[1]. Callbacks are added via `$.on()` which assembles an internal `tree` map to be `dispatch`d once a change happens.
You've probably already seen the API docs for the btn.social SDK, but linking just in case[2]
I fully realize that that's probably due to my own ignorance and no knock on you. However, maybe there's others like me who'd benefit from some more examples.