3 ms·

It's a protocol. You can set up your custom action (including redirects) here: https://hexdocs.pm/plug/Plug.Exception.html#actions/1 https://hexdocs.pm/plug/P

It's a protocol. You can set up your custom action (including redirects) here: https://hexdocs.pm/plug/Plug.Exception.html#actions/1 https://hexdocs.pm/plug/Plug.Exception.html#actions/1 This is how phoenix does those fancy error reports in dev (but not prod) > Probably liveview should do something about that because it's breaking BEAM idioms. Actually now that I think about it, failable actions should probably be wrapped in a task. It's not hard for the liveview to subscribe to task failures and bubble it up to the user as a flash. Not doing so is breaking processes-as-failure-domains concept. The phoenix liveview documentation should probably hoist that sort of guidance to the top and put flashing lights around it.

troupo 3y ago
> You can set up your custom action (including redirects) here: But why would I do that for things that 100% predictable, can and will happen in specific flows? > failable actions should probably be wrapped in a task. It's not hard for the liveview to subscribe to task failures and bubble it up to the user as a flash. How does LiveView know an action is failable? What you propose is akin to trying to solving the halting problem :) Also, not all failures need to be propagated to the user as a flash: - an auth failure should result in a redirect, not a flash - a record not found failure could result in an in-place 404, a redirect to a 404, a redirect to a search page, in a cache lookup etc. - validation errors should be propagated to the form and displayed inline, not as a flash and so on. There are many failure modes and there are just as many recovery modes, the vast majority of which entirely depend on the business logic of your app that LiveView has no idea about
- throwawaymaths 3y ago
  > How does LiveView know an action is failable? Sorry I should have been more clear. You should wrap failable actions in a task if you're calling it from a liveview. > an auth failure should result in a redirect, not a flash That should happen before the socket plug and perform the redirect before even the websocket upgrade.
  - troupo 3y ago
    > You should wrap failable actions in a task if you're calling it from a liveview. For complex, one-off and schduled tasks? Sure. But when my stuff is literally "get one record from the db and display it" why should it be in the task? Just because you're a "let it crash" purist? I don't think even Erlang advocated this. > That should happen before the socket plug and perform the redirect before even the websocket upgrade. Again, that depends. - An unauthed person accessing a link behind login? Yes. Redirect before anything happens - An unauthed person accessing an expired link (e.g. invitatoon, or private preview)? Oh, I have to acces the DB to check that the link is valid/invalid, and show the page saying that the link has expired - A person with some authorisation accesiing some resource that is only partially available to them? Oh, I still have to show some stuff, and hide some other stuff. The world is significantly more complex than "just run it in a task, throw an error, and let Phoenix show a 404 page automatically"
    - throwawaymaths 3y ago
      Honestly it seems to me you've never tried to do it the "Erlang/Phoenix way" because none of these things are a heavy lift at all. You're making things out to be a burden when they're not.

troupo 3y ago

> You can set up your custom action (including redirects) here: But why would I do that for things that 100% predictable, can and will happen in specific flows? > failable actions should probably be wrapped in a task. It's not hard for the liveview to subscribe to task failures and bubble it up to the user as a flash. How does LiveView know an action is failable? What you propose is akin to trying to solving the halting problem :) Also, not all failures need to be propagated to the user as a flash: - an auth failure should result in a redirect, not a flash - a record not found failure could result in an in-place 404, a redirect to a 404, a redirect to a search page, in a cache lookup etc. - validation errors should be propagated to the form and displayed inline, not as a flash and so on. There are many failure modes and there are just as many recovery modes, the vast majority of which entirely depend on the business logic of your app that LiveView has no idea about

throwawaymaths 3y ago
> How does LiveView know an action is failable? Sorry I should have been more clear. You should wrap failable actions in a task if you're calling it from a liveview. > an auth failure should result in a redirect, not a flash That should happen before the socket plug and perform the redirect before even the websocket upgrade.
- troupo 3y ago
  > You should wrap failable actions in a task if you're calling it from a liveview. For complex, one-off and schduled tasks? Sure. But when my stuff is literally "get one record from the db and display it" why should it be in the task? Just because you're a "let it crash" purist? I don't think even Erlang advocated this. > That should happen before the socket plug and perform the redirect before even the websocket upgrade. Again, that depends. - An unauthed person accessing a link behind login? Yes. Redirect before anything happens - An unauthed person accessing an expired link (e.g. invitatoon, or private preview)? Oh, I have to acces the DB to check that the link is valid/invalid, and show the page saying that the link has expired - A person with some authorisation accesiing some resource that is only partially available to them? Oh, I still have to show some stuff, and hide some other stuff. The world is significantly more complex than "just run it in a task, throw an error, and let Phoenix show a 404 page automatically"
  - throwawaymaths 3y ago
    Honestly it seems to me you've never tried to do it the "Erlang/Phoenix way" because none of these things are a heavy lift at all. You're making things out to be a burden when they're not.