Minor documentation updates

[danbits]

When setting up flutter_map with the vector_map_tiles plugin, I noticed a couple of things to update in the docs.

• The basic flutter_map usage example uses a named argument controller. I needed to update the argument to mapController in order to get the example working.
• The section on vector tiles mentions the "mixed" mode for vector_map_tiles, which has been removed. It looks like the paragraph was removed in update vector_map_tiles docs #1361, but that change did not make its way into 1dfdc38. Sorry to bring this up again if that was the intention.

Thank you for all of the work on this package. It's been a joy to use!

[JaffaKetchup]

Hi @danbits. Number 1 seems a bit odd to me, can you show some of your code please? And you are correct about number 2, thanks for pointing that out.

[TesteurManiak]

He's right the parameter name has been changed:

flutter_map/lib/flutter_map.dart

Line 64 in 9e7bf7c

final MapController? mapController;

[JaffaKetchup]

Ah. I'm not sure this is supposed to be like this? I can't remember it being that way in the v3 release? If it wasn't, that needs reverting I think.

[TesteurManiak]

Just checked, the last occurence of controller was in #1289 then it became mapController in #1294

[danbits]

Hey, thanks for the quick responses!

I'm assuming that @TesteurManiak's explanation is sufficient, so let me know if you still want to see any code!

[TesteurManiak]

Well, the thing is that apparently the name mapController is used since the version 2.1 of the package, so changing it back to controller will have an impact on all users who have migrated to 3.0.
I would recommend to deprecate mapController and add back the controller parameter to avoid any breaking changes 🤔

[ibrierley]

Does it really matter, if it was part of a breaking change already ? I.e I would guess most of the old examples out in the wild are already incorrect with other changes anyway (eg layer changes to children), so it feels like simplest would just be to go with it and update the docs to match, or am I missing something (quite likely!) ?

[TesteurManiak]

My main concern is that changing it back to controller in the next release would break project that are using version 3.0.
Usually, when updating code implies breaking change you want to make it a major version bump to avoid current users to encounter a regression in their codebase. The change is small but still, I'm not a big fan of breaking the code of current users of the package.
This might seem a bit overkill, but imo it's better to deprecate anything that can be deprecated before introducing breaking changes.

[ibrierley]

Just checking, are we talking about the same thing here...hasn't it actually been mapController since the dawn of time...? Where has it ever been controller ?

[ibrierley]

Ah, maybe there's a bit of confusion with MapOptions vs FlutterMap mapController (not surprising if so!)

[TesteurManiak]

You're right, I'm the one who inverted controller and mapController 🤣
So yeah there's no problem actually, just updating the documentation to be cohesive with the code

[TesteurManiak]

So yeah, I guess it can be merged (sorry again for my mistake it has been a long day 😅 )

[ibrierley]

Hah no worries, this gets most of us at some point, and one of the reasons we've tried to simplify stuff :D.

Cue someone out there getting confused about bounds next :D

[JaffaKetchup]

Ok, so if we're happy with this, I'll make the changes manually ASAP, as it's just a small changeset. Haven't been following closely (been busy), so please just confirm that's the case :)

[ibrierley]

Fine with me

[JaffaKetchup]

Great. Will add those changes ASAP. Thanks for the heads up!

[danbits]

@JaffaKetchup Should this line be included as well?

[JaffaKetchup]

Yes. Sorry, missed this one!