[GH-ISSUE #109] Using `derive_builder` to avoid repetition with the builder pattern #35

New issue

Closed

opened 2026-02-27 20:22:43 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 20:22:43 +03:00

Owner

Originally created by @marioortizmanero on GitHub (Aug 13, 2020).
Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/109

Originally assigned to: @marioortizmanero on GitHub.

When I was reading the code in src/oauth.rs and src/client.rs I couldn't help but notice all the boilerplate and repetition needed to implement builder patterns for some of the structs declared.

I think this would be a great opportunity to use the derive_builder crate in order to have the codebase more maintainable, easier to read, and consistent. Read more about the features it provides here.

The downside is possibly longer compilation times, but after improving this part in the latest commits I wouldn't think it's much of a problem. And I would like to compare the compilation times before and after the changes before this is merged into master to see how much of a difference there actually is.

Furthermore, using From<String> instead of &str for the builder parameters like this one would avoid an extra allocation for whenever the user passes a String, since the to_owned() can be omitted, and it will be directly moved into the struct. If the user passes a &str it will just be cloned. This is also supported by derive_builder.

Originally created by @marioortizmanero on GitHub (Aug 13, 2020). Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/109 Originally assigned to: @marioortizmanero on GitHub. When I was reading the code in `src/oauth.rs` and `src/client.rs` I couldn't help but notice all the boilerplate and repetition needed to implement builder patterns for some of the structs declared. I think this would be a great opportunity to use the [`derive_builder`](https://docs.rs/derive_builder/0.9.0/derive_builder/) crate in order to have the codebase more maintainable, easier to read, and consistent. Read more about the features it provides [here](https://github.com/colin-kiegel/rust-derive-builder#usage-and-features). The downside is possibly longer compilation times, but after improving this part in the latest commits I wouldn't think it's much of a problem. And I would like to compare the compilation times before and after the changes before this is merged into master to see how much of a difference there actually is. Furthermore, using `From<String>` instead of `&str` for the [builder parameters like this one](https://github.com/ramsayleung/rspotify/blob/master/src/oauth2.rs#L109) would avoid an extra allocation for whenever the user passes a `String`, since the `to_owned()` can be omitted, and it will be directly moved into the struct. If the user passes a `&str` it will just be cloned. This is also supported by [`derive_builder`](https://docs.rs/derive_builder/0.7.1/derive_builder/#generic-setters).