Emit a deprecation warning on an encounter of a `String` field when deriving `Properties`

[its-the-shrimp]

Description

Makes the derive(Properties) macro emit a warning when encountering a field of type String in the struct, which suggests to use AttrValue instead.

Adsing this warning raises 2 questions:

• Should it also report using other string types in Rust's standard library as deprecated?
• Should we fix the tests which now raise the new warning or should we leave them as they are for them to be the tests for the new warning?

Checklist

• [x] I have reviewed my own code
• [x] I have added tests

[github-actions[bot]]

Visit the preview URL for this PR (updated for commit c7bd63e):

https://yew-rs-api--pr3382-add-string-prop-fiel-n2djdgpk.web.app

_{(expires Tue, 29 Aug 2023 15:28:46 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

[github-actions[bot]]

Size Comparison

examples	master (KB)	pull request (KB)	diff (KB)	diff (%)
async_clock	102.316	102.316	0	0.000%
boids	175.516	175.516	0	0.000%
communication_child_to_parent	95.226	95.226	0	0.000%
communication_grandchild_with_grandparent	108.895	108.895	0	0.000%
communication_grandparent_to_grandchild	105.543	105.543	0	0.000%
communication_parent_to_child	92.697	92.697	0	0.000%
contexts	110.885	110.885	0	0.000%
counter	89.208	89.208	0	0.000%
counter_functional	89.923	89.923	0	0.000%
dyn_create_destroy_apps	92.237	92.237	0	0.000%
file_upload	103.544	103.544	0	0.000%
function_memory_game	174.320	174.320	0	0.000%
function_router	352.376	352.376	0	0.000%
function_todomvc	163.354	163.354	0	0.000%
futures	227.708	227.708	0	0.000%
game_of_life	112.298	112.298	0	0.000%
immutable	188.933	188.933	0	0.000%
inner_html	86.012	86.012	0	0.000%
js_callback	112.998	112.998	0	0.000%
keyed_list	201.203	201.203	0	0.000%
mount_point	89.208	89.208	0	0.000%
nested_list	114.501	114.501	0	0.000%
node_refs	96.160	96.160	0	0.000%
password_strength	1582.822	1582.822	0	0.000%
portals	98.235	98.235	0	0.000%
router	318.365	318.365	0	0.000%
simple_ssr	143.640	143.640	0	0.000%
ssr_router	389.579	389.579	0	0.000%
suspense	118.644	118.644	0	0.000%
timer	91.755	91.755	0	0.000%
timer_functional	100.285	100.285	0	0.000%
todomvc	143.697	143.697	0	0.000%
two_apps	89.916	89.916	0	0.000%
web_worker_fib	154.517	154.517	0	0.000%
webgl	88.476	88.476	0	0.000%

✅ None of the examples has changed their size significantly.

[github-actions[bot]]

Benchmark - SSR

Yew Master

Benchmark	Round	Min (ms)	Max (ms)	Mean (ms)	Standard Deviation
Baseline	10	425.275	443.131	431.272	6.992
Hello World	10	753.379	797.022	764.166	14.831
Function Router	10	2499.345	2641.066	2526.388	42.980
Concurrent Task	10	1007.581	1012.871	1009.527	1.538
Many Providers	10	1695.328	1765.432	1727.520	26.692

Pull Request

Benchmark	Round	Min (ms)	Max (ms)	Mean (ms)	Standard Deviation
Baseline	10	424.969	438.085	427.026	3.941
Hello World	10	736.351	756.885	739.457	6.281
Function Router	10	2489.429	2501.457	2495.839	3.725
Concurrent Task	10	1008.343	1011.174	1009.733	0.967
Many Providers	10	1676.206	1735.954	1699.866	24.006

[its-the-shrimp]

I couldn't find a way to explicitly test if a warning is emitted by a derive macro, but there are already some tests that raise this warning, for example here

[futursolo]

I couldn't find a way to explicitly test if a warning is emitted by a derive macro

You can write a failing test in the packages/yew-macro/tests directory, which will check the stderr for the failed tests.

You can add #![deny(deprecated)] at the beginning of the test to make it an error.

[its-the-shrimp]

That's a great idea! I'll do that right away

[its-the-shrimp]

Wait, it doesn't emit a #[deprecated], I tried that but the warning message wasn't too user-friendly, I just used proc_macro_error::emit_warning!

[futursolo]

Wait, it doesn't emit a #[deprecated], I tried that but the warning message wasn't too user-friendly, I just used proc_macro_error::emit_warning!

Does this mean users will have no way to suppress this warning even if they want to?

[its-the-shrimp]

On the other hand, I'm not sure about emitting a #[deprecated] for something that's not supposed to be deprecated

[ranile]

The lints are supposed to be opt-in: https://github.com/yewstack/yew/pull/2882

[futursolo]

On the other hand, I'm not sure about emitting a #[deprecated] for something that's not supposed to be deprecated

If this is not a deprecation, then IMO, it should be classified as a lint (undesirable usage). Which means it is not in the scope of a procedural macro to do it but a tool like clippy.

[its-the-shrimp]

There's something wrong with the way lints are configured, yew-macro's Makefile seemed to have seen no changes after #2882 , and the lints themselves wouldn't appear no matter what I tried