Ask HN: So, what's up with Phoenix (web framework)?

Re:Ask HN: So, what's up with Phoenix (web framework)? by foldr on Saturday August 20, 2022 @06:20AM (#32530868)

LiveView is kind of magical when it works. Where I struggle with it is the constant need to decide between implementing UX logic directly in LiveView or implementing it purely on the client side via the JS helpers. Sometimes you really want the logic on the client side for latency reasons, but then you lose the ability to test it properly (unless you resort to Cypress or something like that).

[ Parent | on HN ]

Re:Ask HN: So, what's up with Phoenix (web framework)? by josevalim on Saturday August 20, 2022 @07:27AM (#32531178)

Generally speaking, if it can be done in the client, it should be done in the client.

Phoenix.LiveView.JS aims to tackle the obvious cases but it also documents a pattern that I tend to use a lot in my apps: https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.htm...

The pattern above has a benefit that the dispatch still comes from Phoenix, so you are not relying on IDs or query selectors to attach functionality. You can see how we use it in Livebook here: https://github.com/livebook-dev/livebook/blob/main/assets/js.... However, if the callbacks get too complex, then you may indeed want to test them via headless browsers.

[ Parent | on HN ]

Re:Ask HN: So, what's up with Phoenix (web framework)? by mstipetic on Saturday August 20, 2022 @07:35AM (#32531219)

Hey Jose, funny to see there answering phoenix questions on a Saturday. Since we're discussing JS, are there any official plans to expose pushing events to the backend directly from JS? What I've been doing (and seen others do) is to assign a hook to a global window variable in the mounted callback, but that seems very hacky.

Is there any reasons why that should be avoided or why you don't want to expose a proper API for that?

[ Parent | on HN ]

Re:Ask HN: So, what's up with Phoenix (web framework)? by josevalim on Saturday August 20, 2022 @07:41AM (#32531246)

You can do it using JS.push from the linked page. You can also use execJS to execute any JS event, including push, from anywhere. I am not sure if this helps though. :)

[ Parent | on HN ]

Re:Ask HN: So, what's up with Phoenix (web framework)? by foldr on Saturday August 20, 2022 @07:59AM (#32531356)

Yes indeed, my natural preference is to do it on the client – but then I can't figure out a way to unit test the behavior. I don't particularly love React overall, but it does make it easy to write tests for client-side UX logic without needing to use headless browsers. This is a fairly big deal, as headless browser tests are slow and cumbersome.

[ Parent | on HN ]

Re:Ask HN: So, what's up with Phoenix (web framework)? by throwawaymaths on Sunday August 21, 2022 @01:13AM (#32537578)

> Where I struggle with it is the constant need to decide between implementing UX logic directly in LiveView or implementing it purely on the client side via the JS helpers.

Welcome to the world of distributed systems. Who owns what piece of state is the perennial difficulty that has plagued developers forever.

You are right though, responsive testability suck with liveview (and honestly just about any be+fe system). I don't see why in the long run it shouldn't be possible to shove a JavaScript engine into the VM (I played around with doing this with mozjs for a bit -- may come back to it) and use it to store a dom for testing.

[ Parent | on HN ]