Add compatibility with documented prior API

[ryanhiebert]

In addition to just providing compatibility with the old API, I want the old API to still be the preferred documented API, so I changed some language in the history and reverted the readme examples to the old api.

Fix #54

[tim-schilling]

I want the old API to still be the preferred documented API

This is not what I would do mainly because I'd prefer to only have 1 way to do things. I don't see the benefit to the library from a technical perspective. There is a DX benefit of having fewer keystrokes, but eh. It's not a frequent occurrence.

Is there a justification I'm missing?

[ryanhiebert]

The benefit I'm valuing most is the clear signal that we haven't and do not intend to break the prior documented API. I'd agree with you to prefer consistency if we weren't dealing with compatibility. You are the lead maintainer, so if you don't care about that signal, or if you think we should expect to break compatibility here at some point in the future, then I'll drop that part of this PR. This is my preference, but no choice is a bad one.

[tim-schilling]

Ah gotcha. Right now, I'm fine with changing APIs when there's a clear and easy migration process. I'll revisit this after the weekend to see if that changes.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (0f1a375) to head (c4ab76f).

Additional details and impacted files

@@            Coverage Diff            @@
##              main       #65   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            6         6           
  Lines          188       190    +2     
  Branches        42        42           
=========================================
+ Hits           188       190    +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.