docs: Support for overriding endorsed plugin implementations

[Gustl22]

DRAFT: It should may land only after the next major release, when functionality is available in stable.

Description of what this PR is changing or adding, and why:

It is now possible to override native or Dart endorsed plugin implementations. This should be reflected in the docs.

Issues fixed by this PR (if any):

flutter/flutter#80374, flutter/flutter#59657, flutter/flutter#137040
See also: flutter/flutter#80374 (comment)

PRs or commits this PR depends on (if any):

Presubmit checklist

• This PR is marked as draft with an explanation if not meant to land until a future stable release.
• This PR doesn’t contain automatically generated corrections (Grammarly or similar).
• This PR follows the Google Developer Documentation Style Guidelines — for example, it doesn’t use i.e. or e.g., and it avoids I and we (first person).
• This PR uses semantic line breaks of 80 characters or fewer.

[sfshaza2]

/gcbrun

[flutter-website-bot]

Visit the preview URL for this PR (updated for commit ee666a2):

https://flutter-docs-prod--pr10891-docs-override-plugins-hpohnkay.web.app

[sfshaza2]

@Gustl22, any reason we can't take this out of draft form and land it? (After a proper review, that is.)

[Gustl22]

@sfshaza2 in the issue description it says in the checklist:
This PR is marked as draft with an explanation if not meant to land until a future stable release.

And I wrote: DRAFT: It should may land only after the next major release, when functionality is available in stable.

I don't know the process. But if this doc is merged and published before the actual feature is released in stable, it may confuses some people as it's not available yet. Otherwise we can mark it as ready and review / merge.

[sfshaza2]

Hi, @Gustl22! Yes, that is the general process. But we have multiple things pulling on us. For one, we don't really like stinky old PRs that sit and sit and sit. The next stable release is quite a ways off. So, sometimes, we add a note that something is coming in a particular release. And, yes, then we must later go clean that up.

I really do thank you for keeping our docs up to date!

[Gustl22]

For one, we don't really like stinky old PRs that sit and sit and sit.

I agree, but I also have to say that I waited more than a month for some reviews, so its not always the fault of the PR author, if a PR gets old and stinky (whereas for Flutter internal reviews in 90% it takes only a few days). And I often notice in stale PRs that the author then got other priorities, because the waiting period was so long.
I don't want to complain, but in some cases it's not that fun to contribute.

Yes, that is the general process.

So do I need to take any action here (marking as ready)? If yes you may want to change the PR default description on how such cases should be handled in the future. In my opinion I just did, what was stated there.

The feature is now available in beta from 3.25.0-0.0.pre onwards, see this commit

[sfshaza2]

Hi, @Gustl22! My apologies. I was not (and do not) blame you! I really appreciate your efforts in keeping our docs up to date. I added the labels that I did in order to mark the PR as ready to merge for the next stable release. That way, I don't keep re-reviewing it to see what is needed.

I'm sorry that contributing to our docs is not fun. I would love to make it more fun, esp because, at the current moment, I am the only writer supporting both Dart and Flutter. :)

thx!

[Gustl22]

No worries, thank you!

I'm sorry that contributing to our docs is not fun.

That was more meant for the flutter repo. Not the docs 😅 But of course it makes fun, otherwise I wouldn't contribute :)

Thank you!