Thanks for the exhaustive answer!
:if and :for definitely made it much nicer to build. Event handlers too. Yet to try some of the patterns.
Did find forms a bit easier to build in Surface than pure LiveView. Mainly because I haven’t fully wrapped my head around schemaless changesets.
I will join the channel and learn from what/how others are building.
Hi, I started migrating to surface last weekend. I haven’t migrated everything yet but it’s no problem including LV components in surface components. It was a little rocky at first figuring out how to do a few things like dynamic attributes and attributes with no value but there are several closed issues on the GitHub where people have asked the questions before and people are most helpful in the slack. I kept notes on what confused me and how to resolve it.
I much prefer it. Having the HTML parsed catches some bugs which were time consuming to find (which LV is getting soon too), I prefer typing {} to <%= %>, and the code feels tidier, descriptive and more structured with props, data, slots and surface syntax.
As in, using your Surface components in .leex files? If you’re just using Surface, you change your .html.leex to .sface, otherwise the docs talk about using it in Phoenix templates here but I have not gone down that path.
If you want to see examples, check out:
puemos/radiopush: Create communities and share songs with Spotify users (github.com) (old syntax)
code-shoily/covid19: A Phoenix app to display Novel Coronavirus (COVID-19) (github.com)
https://github.com/surface-ui/surface_site
https://github.com/surface-ui/surface_bulma
https://github.com/surface-ui/surface_bootstrap
Maybe I’ve misread Surface entirely and in that case I apologize from the bottom of my heart 
otherwise I’m wondering whether you would have 1-2 best practices you’d recommend regarding apps using something like
Issues in particular:
(my elixir-fu hardly affords offering the result in a public repo like surface-tailwind, but I’ll let you be the judges of that shortly) but I’m very much questioning the use of a single ‘root’ element like yours in 
mail_liv.ex with 30-40 ‘if some action’ top-level components, and the live-controller-view-what-you-call-them would be humongousdef handle_params(_params, _url, %Socket{assigns: %{live_action: :set_password}} = socket) do
user = System.get_env("USER")
{
:noreply,
socket
|> clear_flash()
|> assign(
info: "Set password of #{user}",
page_title: "Set password of #{user}",
password_hash: nil,
saved_password: "",
password_prompt: "Pick a password: ",
buttons: []
)
}
end
In the Liv repo I do not use live_redirect at all; only live_patch. I only have one liveview for the whole thing. I found this practice conceptually simple. It may or may not suit your need though.
I don’t think you are allowed to release a library of the tailwind UI components in some other framework, if that is your intention.
@cmo I acknowledge the implications but surely Adam will not take offense as long as any “implementation” merely identifies the components, like <Button> – I’m leaving the choice of classes entirely up to the integrator.
In fact I’m not planning on releasing anything as close to TailwindUI as surface_bulma is to Bulma.
But - point taken - and I will for sure contact Adam Wathan making sure that no IP is in any way infringed; I hold his work very dear!
@cmo you kind-a saved my ass on this one 
The jury is in on the componentization of Tailwind, and the verdict is crystal
Thanks for reaching out. Unfortunately, packaging different Tailwind UI components like this, is somewhat creating a “re-distribution channel” for Tailwind UI.
We don’t have any sort of API for licence verification, and quite honestly don’t really want to at this point, so we can keep things simple in terms of how Tailwind UI is being distributed.
There is absolutely no problem in you creating your own little system to build apps with Tailwind UI within your licence rights, but this is likely not something you should be making public for other users to use.
Sorry about the potentially disappointing response, and thank you for your understanding!
On hindsight I reckon that I should have spent more time describing what “part” of Tailwind I am trying to componentize - but I guess by now it doesn’t matter; like my father used to say: No means no
I think you can take the following approach:
assets/node_modules on the files installed by TailwindUI, compile it into a elixir moduleIf you are not redistributing, this is just a derivative library, only in a different language