Use method instead of trait for .call syntax

[rambip]

This PR completely removes the Callable trait from leptos_reactive, since it was used only in callback.rs and it didn't add anything compared to a method call.

It is technically a breaking change, but only for people that used the Callback trait explicitely. Given that callbacks does not even appear in the book, this will likely affect nobody.

The main motivation for this change is to suppress a compiler warning.

If you were on nightly and used the .call syntax, the compiler would give you a warning saying "you may need to disambiguate .call in the future because a trait method will be called like that". It can be very annoying when someone writes a library for leptos using stable, and someone use it on nightly.

Since method calls take precedence, you will not get any warning with this new version.

I plan to create a chapter about callbacks and generic function props, but the content will depend on whether this PR is accepted

[gbj]

Happy to schedule this for 0.6, but removing a pub trait is a breaking change so it can't be done before that. "Breaking change" here doesn't mean "is it likely to break a bunch of people's code," it means "can it potentially break a previously-working build?" and the answer is "yes, definitely." If use leptos::Callable; compiles and is necessary in 0.5.1 and doesn't compile in 0.5.2, that's the problem.

[rambip]

Right

I will make a different PR to add the missing Copy implementation for SyncCallback

I will also add a .invoke method, so that we can make Callable deprecated and guide towards .invoke (if the name is not too bad)

[rambip]

I just realized I didn't implement From<S: SignalGet> on non-nightly.

The issue with a lot of structs that implement Fn is that the behaviour (like the From trait) is different between nightly and non-nightly.

Since it will likely become worse in the future, it would be nice to enforce some guidelines to make sure the behaviour is as similar as possible for nightly and stable rust

[benwis]

@rambip If you'd like to resolve the conflicts, we can merge this into the 0.6 release branch.