Convenient way to impl View for MyErrorType

[ActuallyHappening]

A very handy pattern I've honed from writing many components in leptos is defining a clonable and thiserror::Error pub enum ComponentError which I then translate into an error ui.
Usually I put this translation layer on a method of the error type. But it would be more convenient if my type natively implemented leptos::View. I've only briefly explored this route, but stopped when I saw the methods on RenderHtml.

Is there an existing easy way to do this? It wouldn't be too difficult I imagine if I used type erasure, but it would be nice to do this in a way that the compiler can optimize away as a zero cost abstraction (thinking some blanket trait impls)

[gbj]

Just going to copy and paste this section of the 0.7 release notes in case it's useful — also happy to discuss specifics in more detail if you want to give more specifics about what you're currently doing/not doing.

Custom IntoView and IntoAttribute implementations

If you currently have implementations of IntoView or IntoAttribute for custom data types, in a way that allows you to use them directly in the view, you should replace those with implementations of IntoRender and IntoAttributeValue, respectively. See this PR for examples.

[ActuallyHappening]

Ahh, very interesting!
The only other problem (which can be solved using trait extentions) is then mapping from a Result<Data, ErrorRenderable> into a non-type erased view, e.g. res.map_view(|data: data| ...) which automatically converts the error type using .into_render() and returns an Either<(mapped), <ErrorRenderable as IntoRender>::Output>

[ActuallyHappening]

Yeah ok, this worked for me:

#[extension(pub(crate) trait MapErrView)]
impl<T, E> Result<T, E>
where
  E: tachys::view::IntoRender,
{
  fn map_err_view<V: IntoView>(
    self,
    f: impl FnOnce(T) -> V,
  ) -> Either<V, <E as tachys::view::IntoRender>::Output> {
    match self {
      Ok(val) => Either::Left(f(val)),
      Err(err) => Either::Right(err.into_render()),
    }
  }
}

Wow, Rust is quite powerful geez!

[ActuallyHappening]

OK after using this pattern extensively, I can say it is pretty good :)
If there was a way to let the compiler infer the associated type, which I'm sure a nightly feature forever awaiting stabilization already exists, this pattern wouldn't require overuse of AnyView. But it works well enough practically and thats what matters :)

[gbj]

Indeed!

struct Foo;

impl IntoRender for Foo {
    type Output = impl IntoView;

    fn into_render(self) -> Self::Output {
        "foo!"
    }
}

gives

error[E0658]: `impl Trait` in associated types is unstable
  --> src/lib.rs:21:19
   |
21 |     type Output = impl IntoView;
   |                   ^^^^^^^^^^^^^
   |
   = note: see issue #63063 <https://github.com/rust-lang/rust/issues/63063> for more information
   = help: add `#![feature(impl_trait_in_assoc_type)]` to the crate attributes to enable

but with impl_trait_in_assoc_type enabled, it does in fact work!