pepicrft
Styled components in Phoenix?
Hi 
I would like to implement a solution like styled-components for Phoenix components such that developers can write their styles using Elixir and the CSS would be generated at compile time. The API would be something along the lines of:
defmodule Components do
use Phoenix.Component
style background_color: "red"
def my_component() do
~H"""
<div class={@styled_class}>
Hello world
</div>
"""
end
end
Because I relatively new to Elixir macros and the compilation process, I’m struggling to map the API to an actual implementation. I was thinking about making style a macro that uses module attributes to store the styles of the components, similar to how attr does, and then have a custom compiler that combines the styles for all the components in the project and outputs a CSS into a configured path.
One piece I don’t know how to do without a sigil that wraps ~H is passing the @styled_class assign. I was thinking about style writing an attr attribute that uses the default: as a way to set the actual value.
Do you think the implementation is sensible? If not, what would you do differently?
I know Tailwind is proposed as the default in Phoenix, but I’m not a huge fan of its mental models so I’m exploring a solution that align with my mental models.
Most Liked
fceruti
Hey Pedro,
I’ve been working on a somewhat similar solution to what you are proposing here. I was planning on open sourcing it once it was a little bit more polished, but the intention from the beginning was to open source it. I’m open on giving access to interested parties now.
The basic architecture is composed of 3 parts: Components, Nomenclators & Hydrators.
Components
Components are a super set of phoenix components with two additional macros: variant and classes (well, also component, I couldn’t override def, as phoenix already does that).
These two macros are used to describe how the component can change depending on either code calls aka, size={:sm} or what class name are to be used for an inner element. Which brings me to the next part
Nomenclators
Nomenclators responsability is to give class names to components and it’s sub elements.
This is the default nomenclator, that spits classes like btn btn-sm btn-outline btn-primary. If you check out the code, class_name/3 can be either _component, _variant, _option, used to variant class names or _component, :classes, _class_name that gives names to classes macros defined in the component.
You can see how just with this, you could just add tailwind inline classes and forget about the next part:
Hydrators
Hydrators responsability is to Hydrate with css the skeleton that nomenclators create. They are auto generated based on: the apps it should go look for components, the parent hydrator and a nomenclator.
This is a very early stage of the DefaultHydrator that users will be able to use as a base.
Next is the auto generated version of a hydrator that has DefaultHydrator as it’s parent.
A few things to note here:
- Notice how it brings all the style and var code as comments from the parent (and it’s parent parent), so that you don’t need to go back and forth trying to understand why styles are the way they are.
- variables can be then injected into ~CSS sigils
- If you modify a sub hydrator the engine is smart enough not to crush the changes. Hydrators are constantly being regenerated.
- ~CSS sigils sorts and properly indents properties with a custom formatter.
- A main focus of this is to have many many themes for my app, and reuse style code as much as possible.
Finally there are a few mix tasks to generate all the files.
Right now I’m working on two things:
- Not your classic component gallery. You’ll not only be able to see all components and it’s possible variations, but have complete access to all variables and css code, so you can edit them right there in your browser, and have those changes be reflected on your code and compiled to css live.
- Actually implement some damn components.
There are more things about this library, but that’s the gist. Oh, and it’s called BuenaVista.
Let me know if you’d interested in collaborating 
fceruti
Yeah, I like it too. I even bought buenavista.dev.
Sure, there are many design decisions that shape this kind of tool. It would be awesome to pool resources, but I totally get if the kind of decision I made don’t make sense to you. Having said that, I really just want to have a library that makes is a contribution to the community, and in my wildest dreams, a reason why people choose Elixir/Phoenix over other language/framework combo.
I’m not particularly invested in the implementation.
cmo
CVA does something similar.
Popular in Questions
Other popular topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
We build reliable cloud platforms for business-critical systems.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Real-time error tracking, performance insights, and observability for devs.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
Courses that'll move you from confusion to "Aha, now I get it!"