Surface vs LiveView

Until we have a declarative API for LV (which we’re already working on), if you want compile-time checks and use features like named slots or context, you need to define a module as vanilla function components do not provide any metadata required for those features.

So my take for now is to define modules for larger components with many of props/data/slots (where compile-time checks are more valuable) and vanilla function components for either private or smaller/simpler components.

Regarding slots, the next version of Surface will replace its original custom slot implementation for the recently introduced built-in slots, so this is not going to be an issue anymore and as soon as we have a unified declarative API, there will be no more limitations as all metadata we need for most (or maybe all) of the other features will also be available.

Generally speaking compiling a module with 100 functions will be faster than compiling 100 modules with one function each. This is very easy to verify yourself and you can try locally. The multiple modules version is 80-90% slower in my quick experiment. And if we are talking about a project, each module is likely a separate file, so there are more disk reads, more mtime checks, etc.

That said, I don’t think folks should generally be worried about creating modules and files. But if most of your modules are single file functions, it may be that you are having the wrong abstraction.

I don’t find any mentioning of reduction of compilation time there.

It is typically best to group related functions into a single module, as opposed to having many modules with a single render/1 function.
From https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.Helpers.html

Why? I’d imagine most of the time the compiler is working on the templates, and it is the same amount of template one way or the other. If anything, large amount of smaller modules can be compiled in parallel, so it should favor smaller modules?

@msaraiva Phoenix Component with Slots is released with LiveView 0.17. LiveView calls them Function Components - and - encourages to group multiple components into one module. The reason given is reduction of compilation time. Instead of 100 modules - it is better to have 10 modules with 10 function components each. However, in Surface, we adopt one module per component. Though Surface provides a lot more features and DX - For simple stateless components - what is the best possible way forward? Writing Function Components and using them in Surface or going ahead with Surface.Component?
Not that I am handling a very big project where compilation time is a concern - it is just to pick your mind on the Future of Stateless Components in both LiveView and Surface!

The problem you’ll have there is that there is no tailwind UI npm package. Well there is one called that but it’s deprecated by tailwindcss 2.

The idea of a Surface tailwind was discussed on GitHub previously.

You can go ahead and make your own component library (like tailkit.com) for Surface but you gotta make it without looking at your tailwind UI purchase for inspiration

not a bad idea - not at all;

but all I initially wanted - was to afford the user some “hangers” / wrappers to apply their classes (and attributes) to, and perhaps offer Surface @click effects - but my stupid decision to attach a screendump of one of the TailwindUI designs totally sidetracked this entire idea;

guess I’ll just crawl back to my little stone in Detroit (Beverly Hills Cop)

I think you can take the following approach:

• let your users install TailwindUI via npm
• Your lib can peek into the assets/node_modules on the files installed by TailwindUI, compile it into a elixir module
• Your user can now use the auto-generated module from Surface

If you are not redistributing, this is just a derivative library, only in a different language

@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