Phoenix 1.7.0-rc.0 is out!

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.

4 Likes

Just trying to figure out how things work. Is it close enough to the way a component callbacks work?

7 Likes

Yes, beautifully done. If you feel like converting it to mermaid and sending that as a PR, I would gladly accept it!

7 Likes

Oh, thanks! Will do and share here :smiley:

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.

3 Likes

@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:

  • In mix.exs: remove tailwind and aliases
  • remove tailwind config from config/config.exs
  • remove tailwind watcher from config/dev.exs
  • remove assets/tailwind.config.js
  • remove the tailwind imports from: assets/css/app.css
  • remove tailwind classes from: 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.

2 Likes

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.

7 Likes

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).

9 Likes

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 :smiley: