Describe the bug
As the title says, the implementation of map_keyed assumes that if the new input has an item with the same key, then that item is only moved and not modified.
There don't seem to be any tests where the key function is not just the identify function.
So i think what likely happened is that the code was refactored and nobody noticed somehow?
To Reproduce
Steps to reproduce the behavior:
#[test]
fn update_keyed() {
create_scope_immediate(|cx| {
let a = create_signal(cx, vec![("a", 1), ("b", 2), ("c", 3)]);
let mapped = map_keyed(cx, a, |_, x| x.1 * 2, |x| x.0);
assert_eq!(*mapped.get(), vec![2, 4, 6]);
a.set(vec![("a", 0), ("b", 0), ("c", 0)]);
assert_eq!(*mapped.get(), vec![0, 0, 0]);
});
}
This will give the error
assertion `left == right` failed
left: [2, 4, 6]
right: [0, 0, 0]
Expected behavior
The test passes
Environment
Describe the bug
As the title says, the implementation of
map_keyedassumes that if the new input has an item with the same key, then that item is only moved and not modified.There don't seem to be any tests where the key function is not just the identify function.
So i think what likely happened is that the code was refactored and nobody noticed somehow?
To Reproduce
Steps to reproduce the behavior:
This will give the error
Expected behavior
The test passes
Environment