mssantosdev
Our take on how to build a frontend style guide with Phoenix Components, Atomic Design and plain CSS, with focus on reusability and code organization.
Trending in Blog Posts
Hey folks,
I just published a post about Hologram’s funding and where the project goes next - the short version:
Curiosum as Main Spons...
New
Hey everyone! :waving_hand:
I’ve published Part 7 of the Building Distributed Systems in Elixir series, where we build core distributed ...
New
So, instead of wasting my afternoon arguing with anonymous handles on X, I turned to my trusty, soulless assistant and said: “Listen, ple...
New
An educational side project in Elixir, Phoenix, and Tauri. I share what I learned while wiring Automerge into the BEAM, including how I s...
New
New article: Elixir Project Structure — From mix new to a Growing Codebase
I’ve published a new article in my Elixir learning series on d...
New
Process labels are useful for visualization and debugging. Here’s why you should use them.
New
Somewhere, right now, a senior engineer is on the verge of a nervous breakdown because his company will not let him switch from Claude to...
New
Other Trending Topics
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
I am happy to introduce the very α version of the new programming language compiled to BEAM.
Welcome Cure.
It has literally three kille...
New
Hi there! We created Gust: A task orchestrator inspired by Airflow.
For those who have never heard about Aiflow, it’s a Python-based wor...
New
Hi everyone!
The first release candidate for the Expert language server project is now available!
We’ve published a press release detai...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #security










Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
zhangzhen
This blog post is worth reading. I wonder how your guys deal with live components and where they are placed in the atomic design?
mssantosdev
Thanks @zhangzhen!
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_.zhangzhen
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.
derpycoder
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
zhangzhen
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.
mssantosdev
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:
Depending on the number of live components, you could even have a file to wrap all of them the same way
core_componentsworks.mssantosdev
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.
derpycoder
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.
zhangzhen
Thank you for your reply.
Would you please give me an example that shows how you do that?
ca1989
What do you use to showcase the components?
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