feat: stylization shorthands

[samyosm]

fix: #241

This PR adds the ability to use style shorthands to str, Span, and Paragraph.

Examples

assert_eq!(
    "hello".red().on_blue().bold(),
    styled("hello", Style::default().fg(Color::Red).bg(Color::Blue).add_modifier(Modifier::BOLD))
)

[codecov]

Codecov Report

Merging #283 (870f88a) into main (83d3ec7) will increase coverage by 0.24%.
The diff coverage is 94.82%.

❗ Current head 870f88a differs from pull request most recent head dda06fd. Consider uploading reports for the commit dda06fd to get more accurate results

@@            Coverage Diff             @@
##             main     #283      +/-   ##
==========================================
+ Coverage   82.71%   82.95%   +0.24%     
==========================================
  Files          36       37       +1     
  Lines        7360     7476     +116     
==========================================
+ Hits         6088     6202     +114     
- Misses       1272     1274       +2     

Impacted Files	Coverage Δ
src/style.rs	85.65% <ø> (ø)
src/widgets/paragraph.rs	98.70% <0.00%> (-1.11%)	⬇️
src/style/stylized.rs	100.00% <100.00%> (ø)
src/text.rs	71.20% <100.00%> (+1.45%)	⬆️
src/widgets/block.rs	85.12% <100.00%> (+0.96%)	⬆️

[joshka]

I'd like to see how this works for styled things outside this module. What imports are needed to make it work, and what do the calls for real-ish ui code look like? E.g. #241 (comment))

Can you please add some integration test for this in tests/stylize.rs?

I suspect that it might make sense to move the impl Styled code to e.g. paragraph.rs etc.

[samyosm]

Can you please add some integration test for this in tests/stylize.rs?

All the necessary tests are already in src/text/stylized.rs. Would it not be better to modify the already existing tests in the tests folder to use this new feature instead? Not just to put it to the test, but also to advocate its usage?

[joshka]

All the necessary tests are already in src/text/stylized.rs. Would it not be better to modify the already existing tests in the tests folder to use this new feature instead? Not just to put it to the test, but also to advocate its usage?

My thinking behind this was that usually I'd organize tests which deal with just the things defined in a module within that module (e.g. here it's just the traits, which don't actually need tests of themselves - which probably means that they could just be added in style.rs perhaps?) Whereas the stylized methods are only really part of the {Text, Paragraph, str ... } when the traits are also imported. So we could add them to text.rs, paragraph.rs etc. but I think it probably makes sense to have them in a single place to make it easy to see how they work.

Does that make sense or am I overthinking it?

Edit: Put a simpler way, unit tests show that the individual types in a specific module work. Integration tests show that modules work together from the perspective of someone using them.

[joshka]

This is looking pretty good.

I'd like some of the other devs to sanity check this (ping @sayanarijit @orhun), but I think it will be good once the missing tests and docs are added.

When adding the tests, have a think about the user of this and what the imports look like. I think it might make more sense for a use to find and import this feature as style::Stylize" instead of text::Stylize`. If so, let's move the entire stylized file under the style mod and re-export the trait(s).

[SLASHLogin]

If this is the preferred way of stylizing text, I think it would be nice to convert examples to use those changes. This would also show how the changes would look like from the user's perspective.

[joshka]

Looking at the examples convinces me that this is really useful (and that stylize does indeed make sense being in the style module).

What documentation is necessary to help users find and understand this feature in the generated docs? (Happy to make that another PR if that would work better?)

[samyosm]

Though styling is introduced here, I think I will add a short explanation for using style and the shorthands here instead, at the module level right such that a user sees it right after clicking the Style module link in the homepage.

By the way, should I advocate the use of style variables or not?

[joshka]

By the way, should I advocate the use of style variables or not?

It's neither here nor there whether people use inline, variables or the easier methods. Each has their pros and cons.

[joshka]

Thanks for your effort in this.