So succinct, loving it!
aiwaiwa
denym
Mhm I might non really see any gain on this. I still have a huge core_compenents and import it through separate modules. So more code for same implementation?
best
0
denym
Minor correction to this which I had to do to make it work:
defmodule MyAppWeb.Components do
defmacro __using__(_) do
quote do
import unquote(__MODULE__).{
Form,
Modal,
Links,
# ....
}
end
end
end
Plus I added it to html_helpers/0 since this is unquoted into live_view/0 anyways.
1
aiwaiwa
To simplify comparison of between version bug fixes, I ended up shortening my proxy to just one component file that delegates to either core or fixed components, which helps me visualize what changes I have brought in. Now when a new version hits, I’ll be able to perform a 3-way diff, in which what I really want to focus on, is bringing any bug fixes from core_component v2 into what becomes my fixed v2, while simply overwriting the core components file.
I will still end up fixing 80% of components with my styling, so I’m not really happy with how much work there will be eventually, but I can’t influence core_compoment file organization to separate purely visual styling from any functional ones.
@parent __MODULE__ |> Module.split() |> Enum.drop(-1) |> Module.concat()
@core Module.concat(@parent, CoreComponents)
@fixed Module.concat(@parent, CoreModComponents)
alias Phoenix.LiveView.JS
# Modal Related
defdelegate modal(assigns), to: @fixed
defdelegate show_modal(js \\ %JS{}, id), to: @core
defdelegate hide_modal(js \\ %JS{}, id), to: @core
# Form Related
defdelegate simple_form(assigns), to: @fixed
defdelegate button(assigns), to: @core
defdelegate input(assigns), to: @fixed
defdelegate label(assigns), to: @fixed
# Form Fields Related
defdelegate header(assigns), to: @fixed
defdelegate table(assigns), to: @fixed
defdelegate list(assigns), to: @core
defdelegate back(assigns), to: @core
defdelegate icon(assigns), to: @core
defdelegate show(js \\ %JS{}, selector), to: @core
defdelegate hide(js \\ %JS{}, selector), to: @core
# Flash Related
defdelegate flash(assigns), to: @core
defdelegate flash_group(assigns), to: @core
# Error Related
defdelegate error(assigns), to: @core
defdelegate translate_error(params_tuple), to: @core
defdelegate translate_errors(errors, field), to: @core
0
asenchi
@aiwaiwa I really like your approach in your first comment. It seems to me that presents a really stable interface for future development in that you can adjust those core components by bringing them into your separate modules without having to change how they’re called. For example, if you start out using ProjectWeb.ShowComponents.header and then want to change it you can simply bring over most of the code from CoreComponents and create your own version in ProjectWeb.ShowComponents without having to update all of your views. Almost abstracting out from the default components to taste.
Thanks for the description. I am curious why you moved to a single file approach from that, what were the limitations you ran into?
0
aiwaiwa
@asenchi Honestly, that is a matter of taste mostly. I just felt it was too much of splitting for something that simple. I wanted to see an overall picture immediately and maintain it at one place.
But here’s a little fly in the ointment. Technically, it’s a naming clash. Core components use themselves, and some of what they will import will be among the fixed, and some among original. I ended up doing import only:, which is an extra housekeeping. In fact it’s only helping to resolve dependency issue within the fixed CoreModComponents. For example.
For the above mentioned configuration, I would have to do something like this:
defmodule ProjectWeb.CoreModComponents do
use Phoenix.Component
alias Phoenix.LiveView.JS, warn: false
import ProjectWeb.Gettext, warn: false
import ProjectWeb.CoreComponentsDelegate,
only: [show_modal: 1, hide_modal: 1, icon: 1, translate_error: 1, error: 1]
Let’s say, I want to add my own fixed version of the <.icon> component and retain its name.
From the core_component perspective, it’s still seeing its own local icon function as component to use in such components as flash and flash_group. So the naming issue is not the only issue here. I would have to bring all the functions that are using icon and also “fix” them.
0
asenchi
I see. I am relatively new to elixir and phoenix, but how do people typically manage upgrades with changes to important files like this? My take was that previously “default” work was confined to the PageController and then people moved that out of the way. I’m interested in understanding the upgrade path between versions if I start using these CoreComponents (please let me know if I am moving off topic here).
2
aiwaiwa
I’m also relatively new! Just about a couple of months. Plus I’m always curious of all the changes between the versions, not being able to track bug fixes at github.
core_components is one of those files that have to be diffed, to patch own core components if needed.
To help with that, I made a little script just to pull a desired Phoenix version, then create a project, then add extra steps, like mix phx.gen.live Accounts User users name:string, so that the generated output for those can be also compared. Online comparison tools tend not to disallow any such final steps, understandably.
Link to the script: Compare Phoenix Versions with extra custom steps like mix phx.gen.live Accounts User users name:string · GitHub
3
aleph-naught2tog
aiwaiwa
It’s pretty much to avoid mentioning my “WhateverWeb” module name and making it universal for any user to simply copy-paste into their module between do and end. It’s taking a current module name, splitting it so that you can get a parent module name and then concatenating it with a CoreComponents atom.
1