Deprecate in favor of react-signature-canvas? Or use it under-the-hood?

[agilgur5]

Hi @blackjk3 , thanks for making this component!

I forked off into react-signature-canvas around 3 years ago when this was no longer maintained. The fork was initially just to have an unopinionated wrapper around signature_pad, i.e. no styles and no other elements rendered other than the canvas -- leaving visuals to downstream developers. This is of course would be a very breaking change for users of react-signature-pad, so that and lack of maintenance led to the persistent fork (though #6 was breaking but was eventually released as a patch version).
Along the way I also added lots of documentation (solving #5 and more), a live demo, various bugfixes and features like built-in trimming, and eventually wrapped the upstream signature_pad in v1.0.0 to have its updates and bugfixes baked in (when I realized the code here was mostly identical (with some React specific changes and with resizing built-in) to that of an old signature_pad release). react-signature-canvas is now currently ~40 commits ahead

I've also been very diligent with SemVer releases as well as backporting lots of fixes to older versions. I'm not perfect, but I've eventually responded to all issues and PRs (and try to respond quickly to most, though some PRs invariably take time, at most a few months, due to the time involvement required for review, edit, merge, bump version, release, and backports), and part of the purpose of v1.0.0 was to drastically reduce the surface area by wrapping signature_pad. Various folks find react-signature-canvas by organically looking at forks and switch to it, with some getting confused occasionally between the two versions.
v1.0.0 has been stable for over a year now and this library hasn't been maintained in a few years, so I thought it might make sense to:

1. Deprecate this library and point to react-signature-canvas, noting that it would have some breaking changes due to the above points

OR

2. Use react-signature-canvas under-the-hood -- this way it should be 100% backward-compatible and the buttons and styling of react-signature-pad can remain as is!

Either option would heavily reduce the maintenance burden and I think clarify the status for many users. I'm happy to do the same for someone else if my fork goes unmaintained for an extended period of time as well. But up to you of course, can leave it as is and close this out if you want.

---

(/begin stats, which really don't mean much.

At some point (~1.5 years ago?), NPM downloads of my fork, react-signature-canvas, started eclipsing your original, react-signature-pad.
Here's an admittedly dumb table I made bc of stat obsessions -- these really don't matter or even necessarily make any sense head-to-head, especially since sample size is small on some stats, updates and CI influence downloads, commits are very different, issues and PR quality vary, size is influenced by features (and docs??), are forks good or bad?, etc, etc, but for anyone else interested:

stat	react-signature-pad	react-signature-canvas	diff
commits ahead	5	~40	~8x ❇
total downloads	~125k	~500k	~4x ❇
weekly downloads	~1.5k	~16k	~11x ❇
min+zip size	~2.9kb	~4.7kb	~1.5x
weekly GH views	unknown	~1k	NaN
weekly GH visitors	unknown	~200	NaN
used by public repos	75	153	~2x ❇
used by public packages	5	11	~2x ❇
stars	114	98	~4/5
forks	63 (net)	35	~1/2
open issues	7	1	~1/7 ❇
closed issues	3	14	~4x ❇
open PRs	3	2	2/3 ❇
closed PRs	4	13	~3x ❇

react-signature-canvas is ~40 commits ahead, is publicly used by 153 repos/11 packages, and has ~500k total/~16.5k weekly downloads, 98 stars, 35 forks, 1 open/14 closed issues, 2 open/13 closed PRs, and ~1k views/~200 visitors per week. (I've also responded to all open issues and reviewed or partially merged all open PRs)
react-signature-pad is publicly used by 75 repos/5 packages and has ~125k total/~1.5k weekly downloads, 114 stars, 63 (net) forks, 7 open/3 closed issues, 3 open/4 closed PRs, and [unknown].

/end dumb stats)