React-native-google-places-autocomplete: How do we use sessions to prevent request for every typed character?

[pytyl]

How can we use sessions with this library to prevent getting billed a request for every character typed? I tried testing a random sessiontoken in the query but I am still seeing requests for every typed character in google cloud console. Here is my query:

query={{
        // available options: https://developers.google.com/places/web-service/autocomplete
        key: "MYKEY",
        language: "en",
        region: "US",
        location: "34.043,-118.267",
        radius: 10000,
        sessiontoken: "thisisarandomtest1234567"
}}

[Lelelo1]

Make a console.log(url) in _request method inside GooglePlacesAutocomplete - it should print the valid url with the parameter sessionToken? It has to make a request for every new input. It could be googles problem?

[Skullcan]

Make a console.log(url) in _request method inside GooglePlacesAutocomplete - it should print the valid url with the parameter sessionToken? It has to make a request for every new input. It could be googles problem?

How do you do that? can you please give some snippet.. thanks.

[LuizFBrisighello]

@Skullcan Any updates?

I guess just using Uuid as recommended by Google is pretty simple. Like this:

        import { v4 as uuidv4 } from 'uuid'
        const sessiontoken = uuidv4()

[...]
        query={{
          key: 'GOOGLE_API_KEY',
          language: 'pt-BR',
          components: 'country:br',
          types: 'address',
          rankby: 'distance',
          sessiontoken
        }}
[...]

[bell-steven]

Feel free to put in a PR.

[LuizFBrisighello]

Just found a problem with uuid, it used crypto-js wich https://stackoverflow.com/a/29836505

[bell-steven]

From some other reading I've done, I believe there are uuid packages that work fine on React Native.

I would really like to try and avoid adding another dependency, especially if it is there to support a single library feature.

React Native doesn't support optional imports (yet -it just landed in metro, but it won't be available until RN 0.63 at a minimum).

[LuizFBrisighello]

I totally agree. Just for test purposes, for now, im just generating the token with a simple function.

  const generateToken = (length) => {
    let result = ''
    const characters = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789'
    const charactersLength = characters.length
    for (let i = 0; i < length; i++) {
      result += characters.charAt(Math.floor(Math.random() * charactersLength))
    }
    return result
  }

[Skullcan]

@Skullcan Any updates?

I guess just using Uuid as recommended by Google is pretty simple. Like this:

        import { v4 as uuidv4 } from 'uuid'
        const sessiontoken = uuidv4()

[...]
        query={{
          key: 'GOOGLE_API_KEY',
          language: 'pt-BR',
          components: 'country:br',
          types: 'address',
          rankby: 'distance',
          sessiontoken
        }}
[...]

Hi, Sorry for the delay in the response.

I ended up following the Docs in the Google Places API and doing exactly what you said.

I have a function to generate a token per component render and stored it in the state:

In the component, I used the same prop you have in your example.. passing this sessionToken

query={{
         key: 'YOUR KEY HERE,
         language: Strings.getLanguage(),
         origin: myLocation,
         location: myLocation,
         sessiontoken: sessionToken,
         radius: '200000',
         components: 'country: br',
         strictbounds: true,
       }}

Edit:
Forgot to put the unction I'm using...
```
const createPlacesAutocompleteSessionToken = a => (a
? (a ^ ((Math.random() * 16) >> (a / 4))).toString(16)
: ([1e7] + -1e3 + -4e3 + -8e3 + -1e11).replace(
/[018]/g,
createPlacesAutocompleteSessionToken,
));
````
Worked like a charm form me.

[bell-steven]

@Skullcan can you put in a PR? I'll get this merged right away.

[Skullcan]

@Skullcan can you put in a PR? I'll get this merged right away.

Sure, I'll get to this when I'm done with work later.

[bell-steven]

What do you all think about how this should be implemented?

There are a couple of ways to go about this, but basically its
1) Add instructions to the readme about how use sessions tokens (it doesn't seems like there are too many steps). This technically does not need to be in the library, because you should be able to do it already in the query prop.
2) Add a sessionToken prop to the library, where, if set to true, would automatically set a session token.

The session begins when the user starts typing a query, and concludes when they select a place and a call to Place Details is made.

Handling for this in the library seems a little more logical to me, but I can hear both sides of the argument.

[Skullcan]

I was going to do following option two.
But both ways works I guess.

I'd say handling in the library is the easier way for the end user.

1. Add a prop to the library, if true, automatically set the session using a default function.
2. Default the prop to false, so it's not a breaking change.
3. Have a prop so people can use their custom function to generate the sessionToken?

The function I posted in the other comment is working fine, and it generates something very close to UUID, but I've not tested in a large scale project so I cannot guarantee it works 100%.

Sample result for the sessionToken using my function: 6a79849f-24c5-45d9-acb8-3203b6a67bf4

[bell-steven]

I prefer option two, although documentation is required either way.

I am extremely weary of adding more props to the library, as there are already almost 50 props available (I am trying to document them all, see my effort here).

In terms of API design, I like numbers 1 and 2 from above. As I said, I don't want to add another prop, especially one that passes in a function, it's a little bit of a blackhole. In addition, passing in a function still limits using a UUID generating library from NPM directly in the package.

How about a session token that has value of either true, false (default), or a string. That way anyone can generate their own UUID however they feel like.

I wouldn't be terribly worried about the accuracy of the UUID generated. The likelihood of a collision is so miniscule....

[Skullcan]

Sure, sounds great to me!
Hope others interested give some feedback and I'll gladly try to implement this.

[bell-steven]

@Skullcan I wouldn't wait around too long for a response. I would tell you to just go for it 😃

[Skullcan]

Sure. Already started something, but didn't had the time to finish yet. Crazy Week.