Trigger source won't cause a Resource to refetch

[cs2dsb]

Describe the bug
Passing a trigger as the source of a Resource doesn't work because Resource creates a memo from the source.

Leptos Dependencies

leptos_reactive = { version = "0.6.12", features = ["csr", "nightly"] }

To Reproduce

use leptos_reactive::{create_resource, create_signal, create_trigger, SignalUpdate};

fn main() {
    let (sig, set_sig) = create_signal(0_usize);
    let trigger = create_trigger();
    
    let _sig_resource = create_resource(
        move || sig(), 
        |_| async move { 
            println!("signal resource fetched");
        }
    );

    let _trigger_resource = create_resource(
        move || trigger(),
        |_| async move { 
            println!("trigger resource fetched");
        }
    );
    println!();
    
    println!("setting signal");
    set_sig.update(|v| *v += 1);
    println!();

    println!("setting trigger");
    trigger.notify();
}

Expected behavior
Expected to be able to trigger a resource to refetch using Trigger::notify()

Additional context
It seems more like a usability/documentation issue than an actual bug. It makes perfect sense when I went and looked at the code of the Resource but it wasn't the behaviour I expected.

As a minimum, updating the documentation of Resource/create_resource to point out that the source is memoized would be good.

One possible way to fix it (assuming you agree Triggers should always trigger Memos and Resources) would be to have the Trigger return a private type that always returns false to PartialEq.

[gbj]

As you note this is 100% a documentation issue; resource memoize the input signal. In fact this is not specific to triggers: since calling .track() on any signal returns (), this would be true for any other signal.track() used in the input signal. The canonical solution is to trigger resources with some kind of incrementing usize signal instead.

The proposed solution to return a ZST that is always != to itself from Track is an interesting one. I'd have to think about what other things it might break, of course -- and it would definitely be a breaking change that may affect user code.