fix: make directive .into() calls consistent

[blorbb]

fixes #2248

added to the directive examples as well.

[blorbb]

Actually, there might be a way to call Default on the parameter if no argument is given to use:, instead of requiring From<()>.
However, this would mean that users might forget to provide an argument and it unknowingly falls back to default. Could be a problem if there is no sensible default for the directive function.
@gbj do you think this is a good idea, or should we just stick to requiring From<()>? Using From instead means that directive authors can't provide both a blanket impl and a 'default', but users could still explicitly use a default with use:dir=Default::default()
Using default might be a breaking change? I don't think calling ().into() is

(Also, not sure why the CI failed above)

[benwis]

Can you run cargo clippy and/or cargo fmt on your repo? The tests are failing because of that @blorbb

[blorbb]

Can you run cargo clippy and/or cargo fmt on your repo? The tests are failing because of that @blorbb

ran both, the only warning I got is about auto traits being unstable from clippy.

[benwis]

Nightly clippy is causing pain, no worries

[gbj]

Thanks, this looks good to me for now. I agree that Default makes more sense than ().into(). It would be a good breaking change to make in the future, as it seems like a more idiomatic way to handle the optional case (and is in line with what we do with optional component props).

[gbj]

(@blorbb You have it marked as draft, I think because of that question — To me this seems ready to merge, unless you're waiting on anything else. Is it ready to go?)

[blorbb]

(@blorbb You have it marked as draft, I think because of that question — To me this seems ready to merge, unless you're waiting on anything else. Is it ready to go?)

yep was just marked draft to decide between ().into() vs Default - makes sense that it can be changed later, I'll reopen it now. Thanks!