Phoenix liveview UI(components) suggestions?

Hello everyone, I’m pretty new to Phoenix, so bear with me here

I am creating a phoenix liveview project and would like some advice on which ui is the best to use. There is an option of using phoenix storybook and surface ui, however when I tried surface ui it gave me an installation error.

* patching lib/alex_web.ex
** (FunctionClauseError) no function clause matching in Sourceror.Zipper.down/1    
    The following arguments were given to Sourceror.Zipper.down/1:
        # 1
    Attempted function clauses (showing 1 out of 1):
        def down(%Sourceror.Zipper{node: tree} = zipper)
    (sourceror 0.13.0) lib/sourceror/zipper.ex:107: Sourceror.Zipper.down/1
    (surface 0.11.0) lib/mix/tasks/surface/surface.init/ex_patcher_move.ex:129: Mix.Tasks.Surface.Init.ExPatcher.Move.last_arg/1
    (surface 0.11.0) lib/mix/tasks/surface/surface.init/ex_patcher_move.ex:135: Mix.Tasks.Surface.Init.ExPatcher.Move.body/1
    (surface 0.11.0) lib/mix/tasks/surface/surface.init/ex_patcher.ex:82: Mix.Tasks.Surface.Init.ExPatcher.move/2
    (surface 0.11.0) lib/mix/tasks/surface/surface.init/file_patchers/phoenix.ex:158: Mix.Tasks.Surface.Init.FilePatchers.Phoenix.append_def_to_web_module/3
    (surface 0.11.0) lib/mix/tasks/surface/surface.init/patcher.ex:113: Mix.Tasks.Surface.Init.Patcher.run_patch_funs/4
    (surface 0.11.0) lib/mix/tasks/surface/surface.init/patcher.ex:28: anonymous fn/3 in Mix.Tasks.Surface.Init.Patcher.patch_file/3
    (elixir 1.15.4) lib/enum.ex:2510: Enum."-reduce/3-lists^foldl/2-0-"/3
    (surface 0.11.0) lib/mix/tasks/surface/surface.init/patcher.ex:27: anonymous fn/3 in Mix.Tasks.Surface.Init.Patcher.patch_file/3
    (surface 0.11.0) lib/mix/tasks/surface/surface.init/patcher.ex:148: Mix.Tasks.Surface.Init.Patcher.log/3
    (elixir 1.15.4) lib/enum.ex:1693: Enum."-map/2-lists^map/1-1-"/2
    (elixir 1.15.4) lib/enum.ex:1693: Enum."-map/2-lists^map/1-1-"/2
    (surface 0.11.0) lib/mix/tasks/surface/surface.init/project_patcher.ex:19:
    (surface 0.11.0) lib/mix/tasks/surface/surface.init.ex:124:
    (mix 1.15.4) lib/mix/task.ex:447: anonymous fn/3 in Mix.Task.run_task/5
    (mix 1.15.4) lib/mix/cli.ex:92: Mix.CLI.run_task/2
    /usr/local/bin/mix:2: (file)
    (elixir 1.15.4) lib/code.ex:1435: Code.require_file/2

Any help would be greatly appreciated and if you know any ui that would be great to use please let me know. Thank you!
@chrismccord @cblavier

How about:


There’s also HyperUI which is Free Open Source and has a lot of components as well


Hi everyone, I am also quite new to phoenix myself and would like some assistance. I was looking at which ui components to use and came across surface ui. I am experiencing the same error mentioned in the first comment and would like to know if this issue in installing surface has been solved?


There isn’t a viable component based UI package for pheonix. There is Phoenix UI but it embeds the style/theme so you’re left overiding classes everywhere, still it might be a good starting place and may get you started quickly. I haven’t used it just looked at the code to understand it as the documentation is minimal.

A viable UI Kit for Phoenix is a huge gap in the ecosystem currently.

For now you basically have to roll your own components.

The best tailwind CSS framework to use IMO is daisyUI.

My rationale is that as you can broadly theme it whilst avoiding hard coding the styling in each component in code, and daisyUI keeps your markup tight and efficient. DaisyUI also avoids unnecessary JavaScript and does the accessibility/aria stuff right. Flowbite doesn’t hence I would avoid, if you prefer flowbite styling then customise your daisyUI theme to suit.

Also be aware that phoenix core components embeds hard coded styles which you can’t override so you have to heavily edit them, but be real careful about changing the “contract” of those components as you need to maintain compatibility with what the generators expect.

The core_components will be a future maintenance burden and it is a weak spot with Phoenix IMO. They don’t provide a proper UI framework but they need just enough for the generators and then go and hard code the styles in a way that requires heavy edits and future update pain. Once you move past generators I would look at replacing core components altogether with your own comprehensive functional components and clean markup and styling.

If you implement your own functional components you will want to give some thought to not following the poor usability of core_components and perhaps use a similar approach to class handling as the phoenix UI library I linked to above. This way by default you can inherit the configured daisyUI theme in your components and customise the styling in your applicsrion html in the specific places where you need to override.

But there is no avoiding “doing the work” to build up your own set of functional components, unless you go with a paid option like Petal and then accept you are in effect on a lagged fork of Phoenix and also can’t practically share your code as they don’t allow distribution of petal components. Not a position I would pay to rush into.

Hope this helps.


@adw632 Thank you so much, I really appreciate it!

You put it better than I could, ty

Petal components are open source and free. There are a few more complex ones that require a subscription, but that package offers a whole lot more like passwordless auth, multi-tenancy, user impersonation, 2FA etc.

1 Like

@adw632 This is something that was brought up in the forums many times before, thanks for wording it so well :clap:.

I started working on a unstyled component library for Phoenix some time ago precisely because of the points you mentioned. At the time, we didn’t want to trap users into using LiveView, so the idea was to do everything using just function components.

Unfortunately, we had to pause it because of some limitations on how hooks are handled… But looking at the current core team priorities, I’m not holding my breath on getting an official solution for that and I’m not looking forward to hacking this into the framework either :grimacing:. Hopefully, someone can use the code as a learning opportunity to create something that fits their own use case.

So, since the focus these days is mostly on LiveView, maybe I can revisit this when we have a more robust component system, but I’m not sure, I feel that function components will always be second-class citizens in the framework.

Phoenix and LiveView are great, but while doing this I remember getting so frustrated with the amount of boilerplate and maintenance work needed to get a (UI) prototype up and running that I was considering using another stack completely :sweat_smile:.


They’re the core building block of a UI in Phoenix. It’s a bit rich calling them second class citizens.

Agree. Getting a functioning app shell and working through the dark arts of a working navigation system is far more work and mystery than it should be. It is enough to walk away when you have a short deadline.

It’s not that you can’t make things work it’s just the work required to make it work.

Also keep an eye on live svelte, it is very complelling approach to getting a liveview and rich client side experience without JS hooks and also component scoped styles.


You are not wrong, but that’s not what I meant either :+1:

Yeah, I think it definitely depends on whether you have the time to hack things together or not (I used to have, but I sure don’t anymore). There is certainly other stuff that people miss on the Svelte/ React world side that we take for granted here (not this though :grimacing:).

1 Like

Does this mean that all major LiveView components have their own UI kit implemented in a closed source manner?

Something like MUI (Material UI is an option, not a must) would fill a huge gap in the ecosystem. Any work or interest going already happening? Maybe we should get things started, I think LiveView would definitely benefit from it!

1 Like