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

[Dominik Csapak <d.csapak@proxmox.com>]

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)