Re: [PATCH yew-comp 1/3] task (viewer): add task download button

["Shannon Sterz" <s.sterz@proxmox.com>]

On Tue Mar 31, 2026 at 2:14 PM CEST, Dominik Csapak wrote:
>
>
> On 3/31/26 2:05 PM, Dominik Csapak wrote:
>>
>>
>> On 3/31/26 1:13 PM, Maximiliano Sandoval wrote:
>>> Dominik Csapak <d.csapak@proxmox.com> writes:
>>>
>>>> similar to what we already have in the ExtJS gui. Currently the default
>>>> is to construct a data URL from the downloaded json in the UI, since not
>>>> all APIs support the 'download=1' parameter (and some can't be easily
>>>> extended).
>>>>
>>>> The download api can be enabled with a setting though, so if at some
>>>> point all consumers use that, we can drop the compatibility code path.
>>>>
>>>> Adds also a small helper to create a temporary 'a' element to click.
>>>>
>>>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>>>> ---
>>>> Longer explanation which api calls do not support the 'download'
>>>> parameter: on PDM, we tunnel the api call to the remote, but this is
>>>> autogenerated code that expects json output. With the 'download'
>>>> parameter, the content type gets set to text/plain, which confuses the
>>>> client.
>>>>
>>>> To fix it, we'd either have to rewrite the auto-code generation to
>>>> handle this case, or expose the underlying client and doit manually, or
>>>> rewrite the remote task api call to to something similar what we do here
>>>> in the ui, collecting json output and returning a final log txt file.
>>>>
>>>> Since having this download button is useful anyway, and implementing any
>>>> of these solutions would take way longer than doing this here, I opted
>>>> for doing that now, and fixing the backend later.
>>>>
>>>>   src/lib.rs         |  21 ++++++++
>>>>   src/log_view.rs    |   7 +--
>>>>   src/task_viewer.rs | 118 +++++++++++++++++++++++++++++++++++++++++----
>>>>   src/tasks.rs       |   6 +++
>>>>   4 files changed, 140 insertions(+), 12 deletions(-)
>>>>
>>>> diff --git a/src/lib.rs b/src/lib.rs
>>>> index 62aa571..65dae68 100644
>>>> --- a/src/lib.rs
>>>> +++ b/src/lib.rs
>>>> @@ -234,6 +234,8 @@ pub mod utils;
>>>>   mod xtermjs;
>>>>   pub use xtermjs::{ConsoleType, ProxmoxXTermJs, XTermJs};
>>>> +use anyhow::{format_err, Error};
>>>> +
>>>>   use pwt::gettext_noop;
>>>>   use pwt::state::{LanguageInfo, TextDirection};
>>>> @@ -271,6 +273,25 @@ mod panic_wrapper {
>>>>       }
>>>>   }
>>>> +/// Helper to download the given 'source' url via a simulated click
>>>> on a hidden 'a' element.
>>>> +pub fn download_as_file(source: &str, file_name: &str) -> Result<(),
>>>> Error> {
>>>> +    let el = gloo_utils::document()
>>>> +        .create_element("a")
>>>> +        .map_err(|_| format_err!("unable to create element 'a'"))?;
>>>> +    let html = el
>>>> +        .dyn_into::<web_sys::HtmlElement>()
>>>
>>> Is it possible a `use wasm_bindgen::JsCast;`
>>>
>>> is missing in this function or file? This does not compile.
>>>
>>
>> yes that's possible. Not sure why, when I compile pdm with this as path
>> dep override, it compiles with no issues, but a 'make deb' fails
>> here...
>>
>
>
> ah found it, we do:
>
> ---
> #[cfg(target_arch = "wasm32")]
> use wasm_bindgen::{self, prelude::*};
> ---
>
> which imports this for wasm32 only and a 'make deb' seemingly builds for
> x86 during the tests
>
> short term solution is to remove the 'cfg(target_arch)' line, but the
> 'real' fix would probably for cargo to build for the correct arch here
> (not sure if that can be configured somehow)

adding:

```
[build]
target = "wasm32-unknown-unknown"
```

to `.cargo/config.toml` might be what you are looking for :)