Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Phoenix html 4 compatibility #147

Closed
wants to merge 16 commits into from
Closed

Conversation

Hermanlangner
Copy link
Contributor

On our App we use exq_ui, and I was going on a dependency update mission.

Exq_ui is using phoenix_html: 3.x but phoenix_html: 4+ has compability issues with it.
Namely in use Phoenix.HTML
As in the error message here

To keep compatibility with previous versions, add {:phoenix_html_helpers, "~> 1.0"} to your mix.exs deps
and then, instead of "use Phoenix.HTML", you might:

    import Phoenix.HTML
    import Phoenix.HTML.Form
    use PhoenixHTMLHelpers

I did exactly as the prompt suggested, which should at least add compatibility for a while. It does generate warnings, but that would involve changing the helpers and I'm not sure what the author would prefer to change it to.

This PR is simply enough to bump dependencies

@ananthakumaran
Copy link
Collaborator

I am open to 4.x, but we need to support 3.x for some time, I am not sure about the reason for the changes in mix.lock file, did you run mix deps.update?. Anyhow see if you can get rid of the warnings and not make changes to mix.lock file.

@Hermanlangner
Copy link
Contributor Author

I am open to 4.x, but we need to support 3.x for some time, I am not sure about the reason for the changes in mix.lock file, did you run mix deps.update?. Anyhow see if you can get rid of the warnings and not make changes to mix.lock file.

I did not consider backwards compatibility, so I did a deps.update all.
I'll revert that but and remove the warnings.
I will still need to add the package for backwards compability though

@@ -1,7 +1,7 @@
import Config

# Print only warnings and errors during test
config :logger, level: :warn
config :logger, level: :warning
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This specifically deals with the warning

warning: :logger :level has been set to :warn in config files, please use :warning instead
  (logger 1.16.1) lib/logger/app.ex:102: Logger.App.default_level/0
  (logger 1.16.1) lib/logger/app.ex:35: Logger.App.start/2
  (kernel 9.2) application_master.erl:293: :application_master.start_it_old/4

Comment on lines -58 to +60
use Phoenix.HTML
import Phoenix.HTML
import Phoenix.HTML.Form
use PhoenixHTMLHelpers
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to provide backwards compability with phoenix_html 3.3 through the helpers package
{:phoenix_html_helpers, "~> 1.0"}, as the built in recommendation in upgrading

Comment on lines +70 to +73
<td>
<.link navigate={Routes.queue_show_path(@socket, job.queue)} class="nounderline">
<%= job.queue %>
</.link>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got rid of the warning to that live_redirect is deprecated

Comment on lines 15 to 18
<.link navigate={Routes.dashboard_path(@socket)} class={nav_link_class(@socket, "Busy")}>
Busy
</.link>
</li>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because I can't render ~H in the helper classes, I split out the nav_link helper to provide the class but we have to use the ./link here

<td class={column[:text_break] && "text-break"}><%= accessor.(item) %></td>
<%= for column <- @columns do %>
<td class={column[:text_break] && "text-break"}>
<%= if column[:link] do %>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to the nav_link approach before, to cator for the least amount of changes, I allowed colums to provide an optional field :link to determind whether it is one.
There are other more invasive/workflow changing ones, I felt that this way was the least disruptive. I'm happy to consider the other approaches

@@ -36,9 +36,10 @@ defmodule ExqUI.MixProject do
[
{:exq, ">= 0.16.2"},
{:exq_scheduler, "~> 1.0", optional: true},
{:phoenix_live_view, "~> 0.18"},
{:phoenix_live_view, "~> 0.20.12"},
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was the last version that supported Elixir 12
phoenixframework/phoenix_live_view@83f3f84

all the mix lock updates were for the live view and html helpers. I tried keeping it to a minimum to make them work

@Hermanlangner
Copy link
Contributor Author

@ananthakumaran
I've tried keeping changes to the minimum, for the html I did use mix format since I couldn't get the indentation looking consistently, there's nothing that changed in format that's not out of the box elixir formatting.
Apologies for the few extra line changes.

For the tests, they were very brittle in expecting changes on the same line, I expanded and red green tested to make sure they were correct, they'll now not be coupled to the html structure as they were before.
In the future it's probably even better to be more explicit than a regex selector.

I've tried pointing out the changes I made to make it easier to review.

I've kept as much to the bare minimum as possible.

I had trouble getting my local back to 12 and 13 so I've not been able to test them, as even the vms aren't great anymore through asdf.

I feel the ci runners should be updated for newer versions of elixir, but this is entirely your call.

Phoenix html 3.3 is fully supported thanks to the helpers package,
but I don't know about older versions of elixir. I'm happy to make small adjustments to cater for it.

I do feel that package versioning exists for this reason of supporting the newer and dropping the older, however this is ultimately your package, and you decide these things.

If we can't reach some point of agreement I'll be forced to fork it, as my time is limited, but I'm doing this to try and give back to a library that's been incredibly useful for us.

"phoenix": {:hex, :phoenix, "1.7.7", "4cc501d4d823015007ba3cdd9c41ecaaf2ffb619d6fb283199fa8ddba89191e0", [:mix], [{:castore, ">= 0.0.0", [hex: :castore, repo: "hexpm", optional: false]}, {:jason, "~> 1.0", [hex: :jason, repo: "hexpm", optional: true]}, {:phoenix_pubsub, "~> 2.1", [hex: :phoenix_pubsub, repo: "hexpm", optional: false]}, {:phoenix_template, "~> 1.0", [hex: :phoenix_template, repo: "hexpm", optional: false]}, {:phoenix_view, "~> 2.0", [hex: :phoenix_view, repo: "hexpm", optional: true]}, {:plug, "~> 1.14", [hex: :plug, repo: "hexpm", optional: false]}, {:plug_cowboy, "~> 2.6", [hex: :plug_cowboy, repo: "hexpm", optional: true]}, {:plug_crypto, "~> 1.2", [hex: :plug_crypto, repo: "hexpm", optional: false]}, {:telemetry, "~> 0.4 or ~> 1.0", [hex: :telemetry, repo: "hexpm", optional: false]}, {:websock_adapter, "~> 0.5.3", [hex: :websock_adapter, repo: "hexpm", optional: false]}], "hexpm", "8966e15c395e5e37591b6ed0bd2ae7f48e961f0f60ac4c733f9566b519453085"},
"phoenix_html": {:hex, :phoenix_html, "3.3.2", "d6ce982c6d8247d2fc0defe625255c721fb8d5f1942c5ac051f6177bffa5973f", [:mix], [{:plug, "~> 1.5", [hex: :plug, repo: "hexpm", optional: true]}], "hexpm", "44adaf8e667c1c20fb9d284b6b0fa8dc7946ce29e81ce621860aa7e96de9a11d"},
"phoenix": {:hex, :phoenix, "1.7.12", "1cc589e0eab99f593a8aa38ec45f15d25297dd6187ee801c8de8947090b5a9d3", [:mix], [{:castore, ">= 0.0.0", [hex: :castore, repo: "hexpm", optional: false]}, {:jason, "~> 1.0", [hex: :jason, repo: "hexpm", optional: true]}, {:phoenix_pubsub, "~> 2.1", [hex: :phoenix_pubsub, repo: "hexpm", optional: false]}, {:phoenix_template, "~> 1.0", [hex: :phoenix_template, repo: "hexpm", optional: false]}, {:phoenix_view, "~> 2.0", [hex: :phoenix_view, repo: "hexpm", optional: true]}, {:plug, "~> 1.14", [hex: :plug, repo: "hexpm", optional: false]}, {:plug_cowboy, "~> 2.7", [hex: :plug_cowboy, repo: "hexpm", optional: true]}, {:plug_crypto, "~> 1.2 or ~> 2.0", [hex: :plug_crypto, repo: "hexpm", optional: false]}, {:telemetry, "~> 0.4 or ~> 1.0", [hex: :telemetry, repo: "hexpm", optional: false]}, {:websock_adapter, "~> 0.5.3", [hex: :websock_adapter, repo: "hexpm", optional: false]}], "hexpm", "d646192fbade9f485b01bc9920c139bfdd19d0f8df3d73fd8eaf2dfbe0d2837c"},
"phoenix_html": {:hex, :phoenix_html, "4.1.1", "4c064fd3873d12ebb1388425a8f2a19348cef56e7289e1998e2d2fa758aa982e", [:mix], [], "hexpm", "f2f2df5a72bc9a2f510b21497fd7d2b86d932ec0598f0210fed4114adc546c6f"},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it be possible to keep phoenix_html 3.x here? Because if we use 4.x here, then it would be very hard to tell whether exq_ui supports 3.x or not and easy for future changes to break the support as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will give this a try this evening, as well as check if it's compatible with an app that's running on 3.x

@ananthakumaran
Copy link
Collaborator

I had trouble getting my local back to 12 and 13 so I've not been able to test them, as even the vms aren't great anymore through asdf.

I feel the ci runners should be updated for newer versions of elixir, but this is entirely your call.

agree, I am ok with dropping 1.12 (which seems to be missing support for Keyword.validate!), adding newer versions can be handled as a separate PR

I do feel that package versioning exists for this reason of supporting the newer and dropping the older, however this is ultimately your package, and you decide these things.

Compared to other libraries I maintain, exq_ui has to be constantly updated thanks to phoenix and phoenix live view changes :). I try to support last 2 versions. phoenix_html 4.x is brand new (December 2023) and I can't drop support for 3.x as we have projects using exq_ui and depend on 3.x

Phoenix html 3.3 is fully supported thanks to the helpers package,

if this is true, I don't have much issues. The changes looks good so far, the only request I have is keep running CI with phoenix HTML 3.x (which got switch to 4.x)

If we can't reach some point of agreement I'll be forced to fork it, as my time is limited, but I'm doing this to try and give back to a library that's been incredibly useful for us.

Fully understand, don't worry too much. If you run short on time feel free to use a fork for some time. Eventually, I or someone else will get the required changes done.

@Hermanlangner
Copy link
Contributor Author

@ananthakumaran I tried bumping down the dependencies, unfortunately it looks like phoenix_html_helpers provides backwards compatibility to phoenix_html 3.3 but it depends on phoenix_html 4.
It will unfortunately not be possible to update while having 3.x as a dependency, which is a bummer, I was hoping to get best of both worlds.

I fully understand the supporting 2+ versions, and hopefully this work does become useful when it becomes time to make the switch!

@Hermanlangner
Copy link
Contributor Author

If this is picked up in the future, I had still missed some manual testing before I was going to merge, I wrongly copy pasted the routes in the navcomponent. Don't let that slip through

@ananthakumaran
Copy link
Collaborator

Thanks for the PR. I will come back to this in a month or two and would surely be useful.

@ananthakumaran
Copy link
Collaborator

@Hermanlangner would you be able to remove the package name change related commits. I want to get this merged. Let me know if you are busy, I can cherry-pick other commits and create a new PR

@ananthakumaran
Copy link
Collaborator

Master supports phoenix html 4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants