I believe you’re mistakenly referring to Tailwind UI, which is a paid offering of pre-styled components using Tailwind CSS.
The Tailwind CSS framework that Phoenix uses is licensed by the MIT License.
I believe you’re mistakenly referring to Tailwind UI, which is a paid offering of pre-styled components using Tailwind CSS.
The Tailwind CSS framework that Phoenix uses is licensed by the MIT License.
Just trying to figure out how things work. Is it close enough to the way a component callbacks work?
Yes, beautifully done. If you feel like converting it to mermaid and sending that as a PR, I would gladly accept it!
Oh, thanks! Will do and share here
May be not the best layout, but here you go:
Mermaid Flowchart:
---
title: LiveComponent - Life Cycle
---
flowchart LR
*((start)):::event-..->P
WE([wait for external changes]):::event-.->U
W([wait for events]):::event-.->H
subgraph w[" "]
direction TB
subgraph i[" "]
direction TB
P(preload/1):::callback-->M
M(mount/1):::callback-->U
end
U(update/2):::callback-->R
subgraph j[" "]
direction LR
A --> |yes| R
H(handle_event/3):::callback-->A{any changes?}:::diamond
end
A --> |no| W
R[render/1]:::callback_req-->W
end
classDef event fill:#fff,color:#000,stroke:#000
classDef diamond fill:#FFFF8C,color:#000,stroke:#000
classDef callback fill:#66B2FF,color:#000,stroke-width:0
classDef callback_req fill:#2C4D6E,color:#fff,stroke:#fff,stroke-width:1
(fixed \n
not understood by :ex_doc
) Making sure my local doc works.
@zachallaun I understand that the CSS files are MIT licensed, but the licensing for the components is ambiguous. As you know, the Tailwind UI components are just some “prefab” HTML with Tailwind classes. How can I know whether or not the component auto-generated by Phoenix contains HTML/CSS code that falls under the Tailwind UI license or not?
For example, a casual inspection of the generated code for the modal in Phoenix 1.7 shows a high degree of similarity with the code for the Tailwind UI modal components. How do I know that the developer didn’t copy the Tailwind UI component code and modify it to create the component that I’m now using?
Add to this that the Tailwind UI license is vague about what it considers a derivative, and states that derivative components and templates are subject to the Tailwind UI license. This would mean that when I see tailwind in the code then there’s no way of knowing, prima facie, whether it’s subject to the Tailwind UI license or not.
The tailwind team helped design the pages:
The Tailwind team also generously designed the new project landing page, CRUD pages, and authentication system pages for new projects, giving you a first-class and polished starting point for building out your apps.
(from Phoenix 1.7-rc released - Phoenix Blog)
So I don’t think that the remarks about the license are really valid.
Having said that, if you don’t want to use tailwind these are the steps you need to take to remove it fully from a new phoenix 1.7 project:
mix.exs
: remove tailwind and aliasesconfig/config.exs
config/dev.exs
assets/tailwind.config.js
assets/css/app.css
components/layouts/*.html.heex
, components/core_components.ex
, controllers/page_html/home.html.heex
The last step is a bit of work, but you’d only need to do it 1 time and then copy it over if you create a new project. The other steps are less then 5 minutes of work.
So your concern is that the Tailwind team, who worked with the Phoenix team to design the new default generated components based on TailwindCSS, are going to begin pursuing legal action against random users generating default templates?
Perhaps it’s my own naïveté, but this reads as some pretty serious FUD to me.
The core_components.ex generator is part of Phoenix and Phoenix is MIT licensed. The tailwind team was kind enough to contribute the designs and markup for it, but it wholly separate from the TailwindUI product (which is fantastic).
Did you ever discuss with them the possibility of a LV headlessui?
@josevalim I just noticed that what the doc says:
On subsequent renders, these callbacks will be invoked:
preload(list_of_assigns) -> update(assigns, socket) -> render(assigns)
So I guess there’s a missing route in the diagram. I can try to fix it, feeling it’s not going to be pretty