chore: switched from set() to update()

[kikoso]

update() should be favoured over set(). From the documentation:

For example, use [update} when value is passed into the class constructor parameters.

This is likely impacting performance during recomposition.

---

Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open a GitHub issue as a bug/feature request before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

Fixes #547 🦕

[kikoso]

Added also contentDescription solving #566 and #532

[bubenheimer]

Thanks for the updates. There are a few places left where state & contentDescription are still in a different order.

Also, are you still planning to deprecate the functions without contentDescription, possibly together with a tracking issue/PR? There are so many similar-looking functions in this file that it would be good not to permanently add even more.

Personally I'd just drop the old functions and make it a breaking change. It's trivial for users to change the calling params as needed.

[kikoso]

Thanks for the updates. There are a few places left where state & contentDescription are still in a different order.

Also, are you still planning to deprecate the functions without contentDescription, possibly together with a tracking issue/PR? There are so many similar-looking functions in this file that it would be good not to permanently add even more.

Personally I'd just drop the old functions and make it a breaking change. It's trivial for users to change the calling params as needed.

The constructors should have now all the parameters in order.

Regarding the breaking change: I would not like to release this as a standalone fix/feature and a breaking change. However, we can pack it together with #516 and/or #521, to minimize the amount of major releases, which are always painful.

[bubenheimer]

Regarding the breaking change: I would not like to release this as a standalone fix/feature and a breaking change. However, we can pack it together with #516 and/or #521, to minimize the amount of major releases, which are always painful.

Sounds fine. Right now the changes are inconsistent. Marker() has a single changed version, while AdvancedMarker() and MarkerComposable() have one changed new and one unchanged version each.

[kikoso]

Regarding the breaking change: I would not like to release this as a standalone fix/feature and a breaking change. However, we can pack it together with #516 and/or #521, to minimize the amount of major releases, which are always painful.

Sounds fine. Right now the changes are inconsistent. Marker() has a single changed version, while AdvancedMarker() and MarkerComposable() have one changed new and one unchanged version each.

@bubenheimer , we will go with a breaking change, so a single constructor with contentDescription.

[bubenheimer]

Please revert 450d842 prior to merge, it was a bad commit.

[kikoso]

Please revert 450d842 prior to merge, it was a bad commit.

This was fixed before the merge, thanks!

[bubenheimer]

Please revert 450d842 prior to merge, it was a bad commit.

This was fixed before the merge, thanks!

@kikoso @dkhawk On my end I see that 450d842 was indeed merged to main and introduced documentation problems.

[kikoso]

450d842

Fixed in #567

[googlemaps-bot]

🎉 This PR is included in version 4.4.3 🎉

The release is available on:

• v4.4.3
• GitHub release

Your semantic-release bot 📦🚀

[googlemaps-bot]

🎉 This PR is included in version 5.0.0 🎉

The release is available on:

• v5.0.0
• GitHub release

Your semantic-release bot 📦🚀