Dioxus web page consumes a lot of memory on updating props inside use_memo

[sumitftr]

Code:

    use_memo(move || {
        if let Some(action_ref) = props.action.read().clone() {
            debug!("Processing action via use_effect: {action_ref:?}");

            match action_ref {
                // some code
            }
        }
        props.action.set(None); // After adding this line, the web page keeps consuming more and more memory
    });

After few more seconds browser replies, "The page is slowing down. To speed up, stop this page"

Steps To Reproduce

Steps to reproduce the behavior:

• Use a Signal<Option<T>> as a props field
• Add some context for the child components
• Read the signal inside use_memo or use_effect
• Update the context and then props inside use_memo or use_effect

Expected behavior

Should consume not more than 200-300 MiB

Screenshots

Environment:

• Dioxus version: 0.7.3
• Rust version: 1.92.0
• OS info: NixOS unstable
• App platform: web
• Browser: Zen Browser

[ealmloff]

You should never update state in use_memo, only derive new state that you return. You should also avoid reading and writing to the same state in the same reactive block. The read will subscribe the reactive block to the state which means it will rerun whenever the state changes. If you write in the same block it can cause the block to rerun, triggering another read and write looping forever

[sumitftr]

You should never update state in use_memo, only derive new state that you return. You should also avoid reading and writing to the same state in the same reactive block. The read will subscribe the reactive block to the state which means it will rerun whenever the state changes. If you write in the same block it can cause the block to rerun, triggering another read and write looping forever

Yes, it is looping forever. Is there a better way to solve this problem except using discriminator pattern?
I removed Signal from Signal<Option<T>> and I was running .take() on that option, like this

    if let Some(new_action) = props.action.take() {
        // some code
    }

But this didn't prevent looping, some how props.action still have the same value
The discriminator pattern made me write a function for each variant of the enum type that I'm using, which is just adding 1 to the action.discriminator and setting the corresponding enum variant

[ealmloff]

What are you trying to do with the action prop? If you want the component to do something based on the action and then set the action to none, I would restructure your logic to not set action and instead just do the thing directly instead of setting the state that will queue the thing to happen

[sumitftr]

What is a good way to add queue functionality? Because the actions will get added to the queue from the parent component and removed from the child component after the action is processed, but will this trigger my child component?
I tried this with mpsc channels before it didn't worked...
Also the queue is a part of the component state so after processing the action removing will require call to write which will cause the same problem

[sumitftr]

Hey, any recommendations on your end?