Mark Bakhit

If we think we might need even more options in the future, we can consider a `dataclass` called something like `EffectHandler` containing both of these args.

Should this be closed in favor of `Deprecate async effects` issue?

I'm in favor of deprecating async effects. It's fairly easy to manage an async task within a sync effect. Any async design we create is going to be over complicated....

I currently think `CSS Modules Imitation Interface` and `Option 3` is the best bet. Let me know if you disagree.

@rmorshea We might want a `type-external-package` tag for issues tracked in core but would result in a completely new package.

Closing this as it's probably better developed and maintained by a community member, if interest arises.

As a note, Conreq currently uses approach 2. Handling this will likely need us to dive deep into the authentication systems of each framework we support.

Maybe the API will look something like this: ```python @component def my_component(): auth_manager = hooks.use_auth() # Returns a IDOM session dataclass that contains any auth data, such the active user...

Should we should beta test this as a standalone hook within `django-idom`, and migrate it to core after IDOM hits `v1`? Similar to how we are currently moving `use_location`/`use_websocket`/etc hooks...

However, that doesn't really provide components the user's authentication information, nor does it give a way to login/logout/validate a user session within IDOM components. Feels a bit disjointed to me.