I think you could clean up your .sface file by splitting it into “logged-in” and “logged-out” parts. Something like:
{#if @auth == :logged_in}
{!-- ... --}
{#else}
{!-- ... --}
{/if}
You could also push the decision not to render anything down to the components, e.g. do the :if={@auth ... inside of the component.
I’ve tried that. However, it somehow sends a larger delta down the wire than what I had in mind in certain cases. Per component :if clause works better, if a little verbose.
Allow me to try to rephrase my questions regarding Surface:
(1) Organizing source code
If I have a <div> that will receive a lot of different content, like <EditableDocument> and <ListOfUsers> and <OrganizationMap> what are my options - if any?
From @derek-zhou I’ve learned that one way is using conditions and remembering to naming all possible outcomes and keeping the handle_params to go with it in one file – which to me looks like 1 router.ex, 1 ‘controller’.ex, 1 ‘.sface’, and a whole pile of logic modules behind this, dealing with persistence and data structures and business logic.
Is that the way FP will like it served? Or can it be broken up somehow - looking at 15/20 different “view objects” (ehh can I say object in here at all 
) like the ones above, I’m trying to find a way to keep things apart.
(2) (Side) effects
If I have a <button> or <a> that should change the content of a number of <div>s around the screen how can I “LivePatch” in more than one place from that click-event?
I sincerely apologize for my questions just simply being sheer bullocks and me presenting my utter n00b-ness; then please call it and, if I may trouble you, please point me to some documentation/code samples setting me straight 
You can create different layout components and use them as per this post. That’s what I’ve started doing. If you have a layout which has several sections, you can create slots for them.
I don’t understand what you mean by “a div receives components”. If that div shows different content depending on the route, use live actions and a case @live_action do.
The idea of putting it all in one LiveView would be insane in my project. It depends on your app. If it’s really simple and has a single layout, then sure. I think in the early phase it’s easiest to be verbose, repeat yourself and create individual views. Then it will become clear what to componentise.
The code you have there is not big. Don’t try to do it perfectly. Make a mess and learn by tidying up.
For 2), The divs that you want to change must accept an assign that is changed by the event that is triggered by the button/link. User input triggers events, events change assigns, assigns change UI. If it is navigating to another route, you patch/redirect and let the mount/params/live_action drive the changes to the UI.
I wanted to use handle_info in a Surface.LiveComponent. Is there a reason why this is not supported but handle_event is?
Because handle_info is for process level messages and a live component (also in plain LV, not Surface) is not a separate process. Live components live in their parent LV process.
So you cannot do a pubsub from a component for example.
Ok, thanks…
How can I then change a prop from a Surface.LiveComponent of a Surface.LiveComponent every 5 seconds?
Its parent LiveView can tell it to do so. Or a component can do so with send_update or send_update_after.
Ok, that’s clear. But how to I change my Surface Components props from the parent LiveView? They should be in the socket.assigns, shouldn’t they?