chore: Allow overriding the route filtering using a ctor param routeFilter

[marandaneto]

💡 Motivation and Context

https://twitter.com/luke_pighetti/status/1774906968886366545

💚 How did you test it?

Using a fake PosthogFlutterPlatformInterface, it was the easiest way to test it and not break or add any public APIs

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• I updated the docs if needed.
• No breaking change or entry added to the changelog.

[marandaneto]

cc @lukepighetti

[lukepighetti]

one way to make this non-breaking for existing customers is to make isTrackableRoute a class constructor argument with a default that can be overridden

you can see that pattern here in firebase_analytics https://github.com/firebase/flutterfire/blob/master/packages/firebase_analytics/firebase_analytics/lib/observer.dart#L17-L22

i bet if you copy paste this but rename the typedef to PosthogRouteFilter folks will be able to use the same filter on firebase_analytics and posthog

you could provide the current one as a default and the new one as an alternative exported from the package

related discussion: https://twitter.com/ue_man/status/1775125806789894437

[marandaneto]

one way to make this non-breaking for existing customers is to make isTrackableRoute a class constructor argument with a default that can be overridden

you can see that pattern here in firebase_analytics firebase/flutterfire@master/packages/firebase_analytics/firebase_analytics/lib/observer.dart#L17-L22

i bet if you copy paste this but rename the typedef to PosthogRouteFilter folks will be able to use the same filter on firebase_analytics and posthog

you could provide the current one as a default and the new one as an alternative exported from the package

related discussion: twitter.com/ue_man/status/1775125806789894437

Makes sense, this tweet convinced me, better to allow the customization, fixes are pushed, thanks for the review.