Multiple client packages

[elie222]

For the client is there a plan to have something similar to the meteor useraccounts packages where there's a different client package for each ui framework. eg. Bootstrap: https://github.com/meteor-useraccounts/bootstrap Material UI: https://github.com/meteor-useraccounts/materialize etc.

Or just letting people build their own UI to fit their projects with some examples?

I know there used to be at least a MaterialUI package for AccountsJS. Is that also being migrated into the new monorepo layout?

[elie222]

Also interested in the state of things at large. Apollo integrations, FB/Google OAuth, migration from multiple packages into the monorepo.

[Aetherall]

There is plenty of possibilities about the future of accounts-js

I give you my opinions, but they are mines only

---

is there a plan to have something similar to the meteor useraccounts packages

Yes, we want this package to be as easy to use as possible

But personally, I am planning to make react-accounts package, which contains a Provider and a set of HOC providing the main functions e.g.

const loginForm = withLogin(({ login }) => (
	<button onClick={()=>login({email: '', password: ''})} />
))

But It's not incompatible with the possibility of having default UI Components (I guess it's even the opposite since we can make use of these HOCs inside the UI Components)

---

I know there used to be at least a MaterialUI package for AccountsJS. Is that also being migrated into the new monorepo layout?

It's not defined yet, I would like to see all of them in the monorepo, so we can move on quickly and stay consistant as babel does.

---

Apollo integrations

The only part I see where we need Apollo compatibility is when we send the tokens.

There is a WIP by myself in order to offer the server multiple ways to store tokens in the request. Headers / Cookies / Body

The choice made on the Transport Storage have to match the client setup

• If the server store on Cookies, the client has to read document.cookies
• If the server store on headers, the client has to read the response
• If the server store on HttpOnly Cookies, the client has to do nothing

The client should be rewritten soon, with to abstract the token management from the transport. This way, we can create a simple ApolloContextLink which can retrieve the tokens from the AccountsClient

const accountsLink = setContext( async request => {
	const tokens = await client.tokenStorage.getTokens()
	return tokens
});

Server Side, using the accounts middleware before hitting your graphql api makes the user available in the request, so you can add it in the graphQL context

---

FB/Google OAuth

OAuth is still something we want to see improve fast, so yes more OAuth Providers will be made. But first, let's release 0.1 stable :)

---