Phoenix v1.5.0 released!

Phoenix Forum Phoenix News
82

To be clear, we have been tracking the node --prefix issues on windows for years, and my comment last June was before someone re-raised the issue later in the year, and all testing on windows confirmed it worked as expected. It seems that it’s still hit or miss in the wild ,but we merged assuming node finally solved the windows issues in this regard. Phoenix master/v1.5 has already reverted this change and will be the previous behavior in the next release :slight_smile:

2 Likes
83

Hey @chrismccord!
Thanks a lot for the confirmation :blush:…
I was suspecting this was a regression precisely because of said comment, but wasn’t sure because I couldn’t find any track of this issue being discussed. Thanks for all the effort!

Also, let me know if I can help with anything while I’m still required to use Windows for development.

Cheers!

84

We all want the installation steps to be more succinct - but unfortunately we can’t because of npm+windows - even though many users were reporting this particular combination was fine.

Please debug the npm issue and send pull requests so the --prefix works as expected.

I think people underestimate how hard this kind of stuff is on Windows. Today I spent most of my day adding coloring support to IEx and ExUnit on Windows and I had to test it on:

  1. Console
  2. Powershell
  3. Linux subsystem
  4. Mingw

And now there is a Windows Terminal - which is unfortunately gated behind a Windows Insider program. I could not install it at the end, even though there are already users requesting the Elixir team to support it.

At this point, I am sure there are specific combinations that I was not able to test the coloring properly and some will still take this as “lack of interest” in supporting Windows, despite the tremendous amount of effort put when implementing this feature compared to other platforms.

15 Likes
85

Love the dashboard <3<3<3

86

While upgrading 1.4 to 1.5 I was looking around for the upgrade guide. The page says that I should be able to find it on the blog. Is this still valid? The guide is in the gist though if anyone’s looking.

87

…And if anyone prefers a video tut, here you go. :slightly_smiling_face:

1 Like
88

Hey,
I keep getting the below error when trying out LiveDashboard behind a proxy. The error is being raised in Phoenix.LiveView.Utils #live_link_info! which I don’t completely understand.

Application Logs

22:11:52.198 IST CONNECTED TO Phoenix.LiveView.Socket in 183µs Transport: :websocket Serializer: Phoenix.Socket.V2.JSONSerializer Parameters: %{"_csrf_token" => "<token>", "_mounts" => "0", "vsn" => "2.0.0"}

22:11:52.209 IST GenServer #PID<0.3784.0> terminating ** (ArgumentError) cannot invoke handle_params nor live_redirect/live_patch to "https://myapp.com/dashboards/my_app%4010.21.1.139" because it isn't defined in MyAppWeb.Router (phoenix_live_view) 
lib/phoenix_live_view/utils.ex:227: Phoenix.LiveView.Utils.live_link_info!/3 (phoenix_live_view) 
lib/phoenix_live_view/channel.ex:652: Phoenix.LiveView.Channel.verified_mount/5 (phoenix_live_view) 
lib/phoenix_live_view/channel.ex:43: Phoenix.LiveView.Channel.handle_info/2 (stdlib) 
gen_server.erl:637: :gen_server.try_dispatch/4 (stdlib) 
gen_server.erl:711: :gen_server.handle_msg/6 (stdlib) 
proc_lib.erl:249: :proc_lib.init_p_do_apply/3 
Last message: {Phoenix.Channel, %{"params" => %{"_csrf_token" => "<token>", "_mounts" => 0}, "session" => "<token>", "static" => "<static>", "url" => "https://myapp.com/dashboards/my_app%4010.21.1.139"}, {#PID<0.3782.0>, #Reference<0.1011715969.1134034946.114165>}, %Phoenix.Socket{assigns: %{}, channel: Phoenix.LiveView.Channel, channel_pid: nil, endpoint: MyAppWeb.Endpoint, handler: Phoenix.LiveView.Socket, id: nil, join_ref: "4", joined: false, private: %{connect_info: %{}}, pubsub_server: MyApp.PubSub, ref: nil, serializer: Phoenix.Socket.V2.JSONSerializer, topic: "lv:phx-FhUWQLy7Dm1ONgEi", transport: :websocket, transport_pid: #PID<0.3782.0>}}

Below is the application configuration.

Rewrite Rule:
https://myapp.com/dashboards/ >> /ext/dashboards

router.ex

scope "/ext" do
 live_dashboard "/dashboards",
      metrics: MyApp.Telemetry,
      live_socket_path: "/dashboards/socket/live"
end

endpoint.ex

 socket "/ext/dashboards/socket/live", Phoenix.LiveView.Socket
89

Reading the docs, I’m wondering if the fact that you’re missing /ext in the :live_socket_path config key is the culprit.

:live_socket_path - Configures the socket path. it must match the socket "/live", Phoenix.LiveView.Socket in your endpoint.

docs

1 Like
90

The /ext will be added by my rewrite rule.
I was able to connect the websocket but channel join crashed

The doc is not updated. The live_socket_path can be configured. See this

91

The scope "/ext" doesn’t affect the string given to :live_socket_path if that’s what you mean by the “rewrite rule”.

92

No, so the connect URI for socket will be wss://myapp.com/dashboards/socket/live this will get rewritten to
wss://<SVC-IP>/ext/dashboards/socket/live when my app gets the request. I can confirm that the websocket is connected successfully.

93

@josevalim Can you maybe help here?

94

When navigating, LiveView checks your router directly to determine which live view module to load. It cannot be aware of any rewrite rules in your proxy.

1 Like
95

Because I’m using LiveDashboard and not LiveView directly, the

live_dashboard "/dashboards",
      metrics: MyApp.Telemetry,
      live_socket_path: "/dashboards/socket/live"

will resolve into LiveView paths.

If I understand correctly, I need to get rid of the rewrite for LiveView Router to work?

96

Yes. The problem is LiveView’s JavaScript reads window.location.href to say where it’s coming from. In your stack trace, you can see

"url" => "https://myapp.com/dashboards/my_app%4010.21.1.139"

is sent through WebSocket and LiveView (on the server) can’t match which live view sent that.

1 Like