wasm.core::cell::panic_already_borrowed for reactive closure passed to child component rendered with <For>

[drakerossman]

Hello @gbj,

I'm currently refactoring my Hackernews Userscript browser extension, and reached for leptos, so thank you very much for creating it.

Now, I am having trouble with the following (full example available at https://github.com/drakerossman/leptos-borrow-example):
Given, I have a top-level component TopLevelWithItems that is supposed to get the filtered_items_from_localstorage from localstorage, currently implemented as just serde_json::json! for testing purposes.

For each of those items, a component FilteredItemWithCheckboxes is to be rendered.

Once the user checks/unchecks one of the chekboxes of such an item, the data in localstorage should update. Again, for testing purposes, this is currently implemented as simply set_filtered_items.set(filtered_items_clone.get()); - it is suposed to just trigger the TopLevelWithItems's update_items_in_localstorage reactive closure by overwriting itself with a copy inside any_checkbox_is_true (currently, regardless of checkboxes state).

Now, I have propagated the filtered_items: ReadSignal<Vec<FilteredItem>> and set_filtered_items: WriteSignal<Vec<FilteredItem>> signals down from the TopLevelWithItems to FilteredItemWithCheckboxes.

The FilteredItemWithCheckboxes now does not render, with the following error:

Uncaught (in promise) RuntimeError: unreachable
    at leptos_borrow_example-1203678d2eba4465.wasm.__rust_start_panic (leptos-borrow-example-f687b591da59da8_bg.wasm:0x198bdb)
    at leptos_borrow_example-1203678d2eba4465.wasm.rust_panic (leptos-borrow-example-f687b591da59da8_bg.wasm:0x198878)
    at leptos_borrow_example-1203678d2eba4465.wasm.std::panicking::rust_panic_with_hook::h61fee46b580473e9 (leptos-borrow-example-f687b591da59da8_bg.wasm:0x13948c)
    at leptos_borrow_example-1203678d2eba4465.wasm.std::panicking::begin_panic_handler::{{closure}}::h75bbc0192c7a22e8 (leptos-borrow-example-f687b591da59da8_bg.wasm:0x15615b)
    at leptos_borrow_example-1203678d2eba4465.wasm.std::sys_common::backtrace::__rust_end_short_backtrace::hcc6a947a7212bd83 (leptos-borrow-example-f687b591da59da8_bg.wasm:0x198b39)
    at leptos_borrow_example-1203678d2eba4465.wasm.rust_begin_unwind (leptos-borrow-example-f687b591da59da8_bg.wasm:0x18b13e)
    at leptos_borrow_example-1203678d2eba4465.wasm.core::panicking::panic_fmt::hf364cc9edfe5d6da (leptos-borrow-example-f687b591da59da8_bg.wasm:0x18e2d3)
    at leptos_borrow_example-1203678d2eba4465.wasm.core::cell::panic_already_borrowed::h7f93fa87ede06e3b (leptos-borrow-example-f687b591da59da8_bg.wasm:0x184b05)
    at leptos_borrow_example-1203678d2eba4465.wasm.core::cell::RefCell<T>::borrow_mut::h675ded536065809d (leptos-borrow-example-f687b591da59da8_bg.wasm:0x156c4d)
    at leptos_borrow_example-1203678d2eba4465.wasm.<leptos_dom::components::each::Each<IF,I,T,EF,N,KF,K> as leptos_dom::IntoView>::into_view::{{closure}}::h09c3c2ef1e47eb93 (leptos-borrow-example-f687b591da59da8_bg.wasm:0x3dd10)

Should I comment out set_filtered_items.set(filtered_items_clone.get());, the error is no longer there.

I am not sure how to fix that.

Thank you in advance.

[gbj]

I'm confused. Wouldn't this just trigger an infinite loop, when you're reading it in the UI?

    set_filtered_items.set(filtered_items.get());

Surely that's not what you want.

[drakerossman]

Hello once again @gbj, and apologies for a very late follow-up, time was unbelievably limited.

As you show, I do not want an endless loop, that's for sure.

I have amended the code so it is now using proper local storage. Please, take a look here: https://github.com/drakerossman/leptos-borrow-example/tree/proper-reactive-logic

The code is functional and does what it should, albeit I have solved the problem in an unsound way by using a set_dummy_signal.

What I want though is that each of FilteredItemWithCheckboxes uses the any_checkbox_is_true closure for updating a part of the filtered_items' Json. And that such an update should signal to the TopLevelWithItems that it should re-render local storage snapshot via read_local_storage closure.

In the end, what I want to know is: how can I propagate signals defined in the children components (and potentially also values thereof) to a parent component?

Thank you in advance.

[gbj]

I'm sorry, I don't have the capacity to read through a 300-line example to try to understand at the moment.

There are several good ways to communicate between parents and children.

You might also want to take a look at the todomvc example in the repo (which triggers writes to localStorage when a child is updated)

If none of those is helpful, and you want to create a minimal example of the problem you're having trouble solving, I'm happy to look at it.

[drakerossman]

I have simplified the code down to 140 lines, plus extracted the most scary looking (but mundane) functions to utils.rs. There's also just one struct FilteredItem being used from filtered_items.rs. Same branch https://github.com/drakerossman/leptos-borrow-example/tree/proper-reactive-logic

Here's the diagram that shows which things are scoped to what. Hope that makes it easier to grasp:

I've taken a look at the docs, and you probably can see most of them are already being utilized in the application in some capacity. The (1) "Pass a WriteSignal" is exactly what I am doing, but creating a dummy_signal does not look sound to me. Maybe I am mistaken, and that's simply the way it should be done.

I see it would be possible to write the logic of print_local_storage at the FilteredItemWithCheckboxes inside any_checkbox_is_true, and that should do the trick, but I would like to keep defined in the TopLevelWithItems, since for the real application it would make sense to keep the logic currently represented by print_local_storage at the top.

Would really appreciate if you'll find some time to review it. Thanks.

[gbj]

A few observations:

I'm not sure why you say your code with the dummy signal is "unsound." Reading through it, this seems reasonable enough. It would be a bit cleaner to use a Trigger rather than the dummy signal.

That said, this isn't how I'd structure this application at all. Basically the state flow right now is that local storage is the state management, and any time you change anything, you write everything into local storage and then read it back out of local storage, and you do the reads and writes imperatively inside rendering code, which is kind of messy. The example doesn't really use signals at all to manage the data -- just this one dummy signal to handle the overall state update cycle, and then the signals in FilteredItemsWithCheckbox to trigger the "serialize during rendering and also update the other signal." This is achieving what you want, but I imagine it will be pretty hard to manage as it scales up.

As I said above: Read through the todomvc example in the repo, which is very similar to what you're doing here, and compare and contrast it with yours. Some notable differences:

• it stores the todos in a signal
• it serializes/stores the todos in an effect, which will respond automatically to changes in any of the signals it reads from in the fields
• it passes signals relevant to the data from parent to child, rather than using a dummy

I have other nit-picking notes, but I think the bigger issue here is paradigmatic/structural, so working through todomvc or even the (shorter, simpler, but fundamentally similar) counters example might be helpful.

[drakerossman]

Thank you very much. Indeed, a better architecture featuring more declarative/fp-ish approach is what's missing, and I was also bugged by the fact I'm passing a redundant value to the set_dummy_signal not being aware that Trigger exists.

And once again thank you for the framework.