2 ms·

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 impleme

by foldr 4y ago

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).

josevalim 4y ago
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.html#module-custom-js-events-with-js-dispatch-1-and-window-addeventlistener 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/events.js 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.
- mstipetic 4y ago
  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?
  - josevalim 4y ago
    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. :)
- foldr 4y ago
  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.
throwawaymaths 4y ago
> 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.

by foldr 4y ago

josevalim 4y ago

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.html#module-custom-js-events-with-js-dispatch-1-and-window-addeventlistener 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/events.js 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.

mstipetic 4y ago
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?
- josevalim 4y ago
  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. :)
foldr 4y ago
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.

throwawaymaths 4y ago

> 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.