Patterns for Propagating Tenants to LiveComponents/LiveViews?
This is a Noob / organizational question. But I just added attribute multi-tenancy to my app. I have the correct tenant loaded on login, placed in the conns, and in the session via
ash_authentication.phoenix.livesession. I am grabbing the tenant from session in a LiveView to be added to reads . For handle_events, and all LiveComponents which talk to the DB, I assume I'll need to pass the tenant in via assigns? Feels like it could get a bit messy, especially for LiveComponents. Does anyone have a pattern they like to use10 Replies
You can use
Ash.set_tenant/1 to set the tenant for an entire process. I'm still on the fence about that method because it can be easy to not realize you're depending on it. For that reason, I tend to just pass the tenant down everywhere. It would be really great if phoenix liveview had some sort of "globals" thing that you can assign to the parent liveview and have it be available everywhereDoes this just put the tenant in pdict and then the datalayer knows to check there?
Yep! Although Ash is responsible for picking it up, not the data layer
Ahh gotcha, that makes more sense
Not sure if I should make a new thread for this but I'm confused as to how to implement PubSub to work with tenants? If I have a pubsub notifier which says when something is added, and is added to the a list, I will get updates across tenant. Seems like I'll need to prefix a tenant_id somehow?
There are two ways to go about it. In your message template,
:_tenant can be used
publish :updated, [:_tenant, "updated"] for example
But you can also look into the event's changeset or query
They both have a tenant keyIs the tenant always accessible via :_tenant in the DSLs??
no, its just a special thing that
publish and publish_all do 😆ahhh gotcha. Thanks 🙂