Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2.0b2 - withClientHints() returns a promise, when headers are provided #705

Open
devenbj opened this issue Feb 2, 2024 · 1 comment
Open

Comments

@devenbj
Copy link

devenbj commented Feb 2, 2024

Library version
v2.0.0-b2

Describe the bug
Following the example: https://docs.uaparser.js.org/v2/api/ua-parser-js/idata/with-client-hints.html for server-side. The example returns a promise with the current client data when the .withClient.Hints() function is added. This generates console errors from the sample code.

To Reproduce
Create a page with the v2.0.0b2 version of ua-parser-js.
Copy and paste the demo code.
Browser errors immediately on the .withClientHints() console.log statements.

Expected behavior
An object with the parsed results. This works as expected when not using .withClientHints.

Screenshots

Desktop (please complete the following information):

  • OS: Ubuntu 23.10
  • Browser: Brave
  • Version: 121

Smartphone (please complete the following information):

Additional context
It is clear the withClientHints piece is functioning, as my browser changes from Chrome to Brave. For my code, I am feeding in an array of 7 different browsers configs (including Mac OS and iOS), and they all come back as Linux / Brave (my dev platform). They only return when I nest the console.log inside a .then response. When I drop the .withClientHints(), the function returns the data as expected (Brave is identified as Chrome).

@castarco
Copy link

castarco commented Feb 6, 2024

I also think that it does not make much sense to return a promise when the result can be computed in a complete synchronous way (as the data is already provided).

The stated return type could be easily conditioned to the passed parameters to fix that interface problem.

Note: I'd contribute a fix if it wasn't because I already paid for the privative license, my work would report benefits only to the lib owner, and I'm not happy with how our doubts are not being resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants