React-native-firebase: 馃敟 Cannot send array/object in logEvent in v6

Created on 14 Nov 2019  路  10Comments  路  Source: invertase/react-native-firebase


Issue



In v5 you could provide arrays / objects within the logEvent params object, and such usage is even provided in Firebase's own examples.

In v6 logEvent is restricted to having strings, numbers and booleans as values and it throws an exception if any other type is provided:

Screenshot of error

It seems this is a major limitation in v6 compared to what Firebase analytics offers.

_(Edit: initially wrote getEvent instead of logEvent, still wrong in the title)_


Project Files






iOS

Click To Expand

#### `ios/Podfile`: - [ ] I'm not using Pods - [x] I'm using Pods and my Podfile looks like:

# N/A
#### `AppDelegate.m`:
// N/A


Android

Click To Expand

#### Have you converted to AndroidX? - [ ] my application is an AndroidX application? - [ ] I am using `android/gradle.settings` `jetifier=true` for Android compatibility? - [ ] I am using the NPM package `jetifier` for react-native compatibility? #### `android/build.gradle`:

// N/A
#### `android/app/build.gradle`:
// N/A
#### `android/settings.gradle`:
// N/A
#### `MainApplication.java`:
// N/A
#### `AndroidManifest.xml`:
<!-- N/A -->


Environment

Click To Expand

**`react-native info` output:**

  React Native Environment Info:
    System:
      OS: macOS 10.14.6
      CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
      Memory: 149.97 MB / 32.00 GB
      Shell: 5.0.9 - /usr/local/bin/bash
    Binaries:
      Node: 12.8.1 - /usr/local/bin/node
      Yarn: 1.17.3 - /usr/local/bin/yarn
      npm: 6.11.3 - /usr/local/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    SDKs:
      iOS SDK:
        Platforms: iOS 13.1, DriverKit 19.0, macOS 10.15, tvOS 13.0, watchOS 6.0
    IDEs:
      Android Studio: 3.5 AI-191.8026.42.35.5791312
      Xcode: 11.1/11A1027 - /usr/bin/xcodebuild
    npmPackages:
      react: 16.9.0 => 16.8.3
      react-native: 0.61.4 => 0.59.9
- **Platform that you're experiencing the issue on**: - [ ] iOS - [ ] Android - [ ] **iOS** but have not tested behavior on Android - [ ] **Android** but have not tested behavior on iOS - [x] Both - **`react-native-firebase` version you're using that has this issue:** - `6.0.3` - **`Firebase` module(s) you're using that has the issue:** - `Analytics` - **Are you using `TypeScript`?** - `Y` & `3.7.2`




Think react-native-firebase is great? Please consider supporting all of the project maintainers and contributors by donating via our Open Collective where all contributors can submit expenses. [Learn More]

Analytics In Progress >= 6

Most helpful comment

@plaa and others, @russellwheatley has fixed this in #3219 which has been merged - this will be available in a upcoming release, thanks

All 10 comments

Hmm I'm not sure why that's been implemented like that. From memory one of the platforms didn't accept nested data... I'll take a look into it.

Hello 馃憢, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require the community's attention?

This issue will be closed in 15 days if no further activity occurs.
Thank you for your contributions.

Would still appreciate knowing whether this will be implemented or not.

Would still appreciate knowing whether this will be implemented or not.

+1

Would still appreciate knowing whether this will be implemented or not.

Same here.

same here

I've used with params = [...]

const logger = async (name, params) => {
  await analytics().native.logEvent(name, params);
};

Hello 馃憢, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require the community's attention?

This issue will be closed in 15 days if no further activity occurs.
Thank you for your contributions.

Still waiting on whether this will be implemented or whether we need some
workarounds.

@plaa and others, @russellwheatley has fixed this in #3219 which has been merged - this will be available in a upcoming release, thanks

Was this page helpful?
0 / 5 - 0 ratings