You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[unified_analytics] Send enabled_features as an event parameter rather than a user property (#2007)
Fixesflutter/flutter#147327.
**Summary.** The `Analytics` constructor accepts a list of "enabled features" for the current user of the whatever tool is in use ([src](https://github.com/dart-lang/tools/blob/3934675f1595ed2fee2297d7d1cc96beaaa50c9e/pkgs/unified_analytics/lib/src/analytics.dart#L39-L42)). For example, in the Flutter tool, this will be a comma-delimited list of `flutter config` items set to `true` (explicitly by the user). When any event is sent off to Google Analytics, this list will be included as a _user property_ with the key "enabled_features".
See the parent issue. This list is prone to getting truncated due to the low character limit of user property values. This PR instead sends them as event properties. This has a _much_ higher character limit of 500, which is hopefully sufficient (even if it is not, it would be a huge improvement over the current limit of 36, which makes collecting enabled features near-useless).
However, this creates a pitfall. If any new `Event` decides to include an `enabled_features` event property (and also passes a non-null argument for the `enabledFeatures` parameter in the `Analytics` constructor). There are a few ways handle this:
1. Do nothing. The likelihood of this happening is extremely low (but it will be quite confusing if it does happen).
2. Create an `Event._` constructor that throws an exception if the `eventData` map includes an entry with a key of `enabled_features`. Re-route all of the existing constructors to utilize this one. This working depends on newly added events following the pattern of using `Event._` instead of doing initialization themselves; but I suspect folks adding new events will naturally use the existing ones for inspiration, so this is fine to me.
3. Similar to 2, add this validation logic but instead do so in `generateRequestBody`. This keeps the validation logic much closer to the logic that inserts `enabled_features`, so it will make sense to first-time maintainers slightly more quickly. This also would require the least work to implement. The downside is that no exception would appear until `send` is called, and that exception would be thrown asynchronously.
I suspect 2 is probably the way to go, so I went ahead and implemented that. Let me know if you have a differing opinion. I made this is a separate commit, so it would be easy to revert.
---
<details>
<summary>Contribution guidelines:</summary><br>
- See our [contributor guide](https://github.com/dart-lang/.github/blob/main/CONTRIBUTING.md) for general expectations for PRs.
- Larger or significant changes should be discussed in an issue before creating a PR.
- Contributions to our repos should follow the [Dart style guide](https://dart.dev/guides/language/effective-dart) and use `dart format`.
- Most changes should add an entry to the changelog and may need to [rev the pubspec package version](https://github.com/dart-lang/sdk/blob/main/docs/External-Package-Maintenance.md#making-a-change).
- Changes to packages require [corresponding tests](https://github.com/dart-lang/.github/blob/main/CONTRIBUTING.md#Testing).
Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.
</details>
0 commit comments