This blog post is worth reading. I wonder how your guys deal with live components and where they are placed in the atomic design?

Thanks @zhangzhen!

I wonder how your guys deal with live components and where they are placed in the atomic design?

Great question - we don’t use live components yet. Assuming they are more complex than the “static” ones, I would create them as organisms with the prefix live_.

Function components are implemented in the form of functions that take the assigns param, which means one module defines multiple function components. Live components are implemented in the form of modules, which means one module defines only one live component. Can you give some details about how you create them as organisms? It would be better if you could give me one example.

I’m glad this resurfaced.

I loved the defdelegate approach to avoid cluttering up the Organism.

Will implement this in my own project, that is just starting out.

Have you considered using Storybook?

I am bit scared of business logic seeping into the components over time, so I was thinking of separating components as well as adding storybook to avoid those pitfalls.

Plus whenever we have to change something in a component, we won’t have to jump through our UI to make it happen.

https://github.com/phenixdigital/phoenix_storybook

I really did consider phoenix_storybook. I heard this good project from thinking elixir podcast and read its documentation. Does it export its results as core_components.ex, so i can easily replace the default one with this? By the way, currently I’m using flowbite pro to build my frontend.

Sorry for the delay. I’ve changed my mind about the first answer.

I would probably wrap a functional organism in a live component, and all data required for that organism would come from the live wrapper. I believe you will have access to the CoreComponents from a live_component by default, so the following should work:

defmodule AppWeb.LiveComponents.Form do
  use AppWeb :live_component

  def render(assigns) do
    ~H"""
    <.functional_organism arg={@arg} arg2={@arg2} />
    """
  end
end

Depending on the number of live components, you could even have a file to wrap all of them the same way core_components works.

Thanks @derpycoder!

I’m not a big fan of storybook (the react one), so I didn’t consider using phoenix_storybook. I prefere https://patternlab.io/ instead. Thanks for the suggestion, maybe I’ll test it in the future and try to connect everything.

The phoenix version of storybook will become part of the Phoenix itself, eventually.

Well, I hope it does.

If not part of it, then at least reach v1, so that I can use it to my heart’s content.

Thank you for your reply.

Would you please give me an example that shows how you do that?

What do you use to showcase the components?

• A custom tool?
• A demo Phoenix project?
  • if so, in the same repo as the component library or in a separate one?
• Nothing
• Something else

I tend to don’t like storybook as well.
What I love instead is to have unit tests and assert the produced html (this may be overkill, but I find myself refactoring components very often…)

Cheers