[PATCH proxmox-yew-comp 1/1] key value list: accept objects as data

[PATCH proxmox-yew-comp 1/1] key value list: accept objects as data

[Stefan Hanreich]

When setting the value, convert any objects into a list of (String,
Value) pairs and then set the data.

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
---

Notes:
    Not sure about this change, but accepting objects seems reasonable
    here? Probably good if someone with more clue about the component can
    chime in. Fixes the issue with resetting the prepared answer form for
    me.

 src/key_value_list.rs | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/src/key_value_list.rs b/src/key_value_list.rs
index e6377b8..f579b04 100644
--- a/src/key_value_list.rs
+++ b/src/key_value_list.rs
@@ -242,6 +242,14 @@ impl ManagedField for KeyValueListField {
                         .unwrap();
                 self.set_data(&data);
             }
+            Value::Object(map) => {
+                let values: Vec<(String, Value)> = map
+                    .iter()
+                    .map(|(key, value)| (key.clone(), value.clone()))
+                    .collect();
+
+                self.set_data(&values);
+            }
             value => {
                 let data = serde_json::from_value::<Vec<(String, Value)>>(value.clone()).unwrap();
                 self.set_data(&data);
-- 
2.47.3

applied: [PATCH proxmox-yew-comp 1/1] key value list: accept objects as data

[Thomas Lamprecht]

On Tue, 26 May 2026 18:49:02 +0200, Stefan Hanreich wrote:
> When setting the value, convert any objects into a list of (String,
> Value) pairs and then set the data.

Applied, thanks!

[1/1] key value list: accept objects as data
      commit: e623cb531f1fda75ece6cdff1f169d0245c48d95

Re: [PATCH proxmox-yew-comp 1/1] key value list: accept objects as data

[Dominik Csapak]

as it's already applied it does not matter for now, but
IMHO this is the wrong fix for the problem

Either the KVList assumes/accepts a list (vec<(string, value)>)
or it works with hashmap/btreemaps

it does not make sense really to enforce a list everywhere but
internally also accept a hashmap?

this will only cause confusion in the future when a user either
enters the same key twice (be it by accident or with intent)

or if someone needs to have multiple same keys in a different context.

Since the use-case for this for now seems to be only a hashmap,
I'd argue we should rework that widget so it works with hashmaps only

this could even improve the usability (e.g. checking if a key already 
exists)

if we do this we should rename it something appropriate e.g.
PropertyMap (suggestion by dietmar)

@Christoph, can you look at that after the release?
(Since you used it in the auto-installer ui part)
If not i can take a look too