NGRX Integration

[ramarivera]

It would be nice if this library provided built-in integration with NGRX ecosystem, meaning (at least) using a state management solution where the different actions would be published and consumable for other apps already working with NGRX.

As a nice to have, somehow driving all the auth flow steps purely through ngrx/effects sounds like a very good example of the power and expressivity state management + rxjs can provide.

What say you @leonardochaia ?

[leonardochaia]

Maybe we can add another Angular Library project which uses the current "core" implementations of the protocol through NGRX actions and exposes the state in the store.

I'm planning on moving the current AuthService into a separate module which would work as a facade of the "core" implementations. This facade is probably what consumers would use.
Maybe we could expose the same with NGRX, or override the facade's implementation.

[ramarivera]

So that way each Library would only expose their public api / facade, right?
Is that AuthService refactor a blocker for hooking NGRX, or the public api of the core library is enough right now?

Does it make sense, in the case of the current library, to expose anything else than the facade? If not, then the core implementation should be moved to somewhere non public but at the same time importable from a brother library?

[leonardochaia]

So that way each Library would only expose their public api / facade, right?

Kind of, we still wanna expose the core or parts of it just in case.. you know.. for hacks and whatnot.
Exposing those would also allow people having custom identity providers to make desired tweaks, and also, just in case, to allow to quickly/dirty fix bugs before we can provide a solid solution.

Is that AuthService refactor a blocker for hooking NGRX, or the public api of the core library is enough right now?

I believe that the public API of the current angular-simple-oidc project should be enough. If not, feel free to expose more of it in your PR and we'll think it through.

Does it make sense, in the case of the current library, to expose anything else than the facade? If not, then the core implementation should be moved to somewhere non public but at the same time importable from a brother library?

Yes, besides my first comment, another option would be to create a separate public package for the core and reuse it in both projects, although I do not believe it to be currently necessary if the core + "simple" implementation is done properly in modules for tree-shaking.
Which makes me think that we should create a separate module for most of the /token folder (which would be the "core") except for the clients, only token validation and all different helpers.
I can do that in master if you'd like before you start with your PR.

Of course let me know your thoughts.

[leonardochaia]

A step closer to this is #24
Other implementations could reuse everything from angular-simple-oidc/core and would have to pretty much re-implement the rest.

Most likely more logic can be moved to the core.