feat: added VITE_API_VERSION parameter to test the API in dev mode

[swastikCommits]

Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context.

Added VITE_API_VERSION env variable to .env.example with a default value of 3.
Updated the PRODUCT_URL function to use the API version from env variables.
Updated the getProductAttributes method in ProductsApi class to use the API version parameter.

@VaiTon We must update the README to address the new API version configuration option which would be helpful for the developers to test it.

Fixes #401

---

Checklist:

Author Self-Review:

• I have performed a self-review of my own code.
• I understand the changes I'm proposing and why they are needed.
• My changes generate no new warnings or errors (linting, console).
• I have made corresponding changes to the documentation (if applicable).

LLM Usage Disclosure:
Please be transparent about the use of AI assistance.

• If I did use an AI Large Language Model, I have reviewed the generated code/text to ensure its accuracy, security, and relevance to the project's context and licensing.

Triggering Code Review:

• You can request an AI-powered code review by commenting /gemini review on this PR after it's been created.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
openfoodfacts-explorer	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 20, 2025 4:35pm

[gemini-code-assist]

Hello @swastikCommits, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

Summary of Changes

This pull request introduces the VITE_API_VERSION environment variable to allow developers to test different API versions in development mode. It updates the .env.example file with a default value of 3 for this variable. The PRODUCT_URL function and the getProductAttributes method in the ProductsApi class are modified to utilize the API version specified in the environment variables. This change addresses issue #401.

Highlights

• Feature: Introduces VITE_API_VERSION environment variable for API version testing in development.
• Configuration: Updates PRODUCT_URL function and getProductAttributes method to use the API version from environment variables.

Changelog

• .env.example
  • Added VITE_API_VERSION with a default value of 3.
• src/lib/api/product.ts
  • Modified getProductAttributes to use VITE_API_VERSION from environment variables, defaulting to '2' if not set. (line 14,15)
• src/lib/const.ts
  • Updated PRODUCT_URL function to use VITE_API_VERSION from environment variables, defaulting to '3' if not set. (line 13,14)

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

---

A version's call,
In env, it stands up tall,
Dev tests with glee.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a new environment variable VITE_API_VERSION to allow developers to test different API versions in development mode. The changes seem reasonable and address the issue of testing different API versions. However, there are a few points that need to be addressed before merging.

Summary of Findings

• Missing README update: The pull request description mentions that the README should be updated to reflect the new API version configuration option. This update is currently missing.
• Default API version consistency: The default API version is set to '3' in src/lib/const.ts and '2' in src/lib/api/product.ts. This inconsistency should be resolved.

Merge Readiness

The pull request is not ready to be merged due to the missing README update and the inconsistent default API versions. These issues should be addressed before merging. I am unable to approve this pull request, and users should have others review and approve this code before merging.

[swastikCommits]

/gemini review

[gemini-code-assist]

Code Review

The pull request introduces a new environment variable VITE_API_VERSION to allow developers to test different API versions in development mode. The changes seem reasonable and address the issue of testing different API versions. However, there are a few areas that could be improved for clarity and maintainability.

Summary of Findings

• README update: The PR description mentions the need to update the README to reflect the new API version configuration option. This is crucial for developers to understand how to use the new variable.
• Default API version consistency: The default API version is hardcoded as '3' in multiple places. It would be better to define it as a constant in a single location to ensure consistency.

Merge Readiness

The changes are generally good and address the intended functionality. However, before merging, it's important to update the README with instructions on how to use the new VITE_API_VERSION environment variable. Also, consider defining the default API version in a single constant for better maintainability. I am unable to approve this pull request, and recommend that others review and approve this code before merging.

[swastikCommits]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a new environment variable VITE_API_VERSION to allow developers to test different API versions in development mode. The changes seem well-structured and address the issue described. However, there are a few points that could be improved for better maintainability and clarity.

Summary of Findings

• Redundant API Version Definition: The API version is defined both as an environment variable and as a constant. This redundancy could lead to inconsistencies if not managed carefully. Consider relying solely on the environment variable with a default value.
• Documentation Update: The README needs to be updated to reflect the new API version configuration option, as highlighted in the pull request description. This is crucial for developers to understand how to use the new feature.

Merge Readiness

The pull request is almost ready for merging. Addressing the redundant API version definition and ensuring the README is updated would significantly improve the quality of the code. I am unable to directly approve the pull request, and recommend that others review and approve this code before merging. However, I recommend that the pull request not be merged until the aforementioned issues are addressed.

[swastikCommits]

/gemini review

[gemini-code-assist]

Code Review

The pull request introduces a new environment variable VITE_API_VERSION to allow developers to test the API with different versions in development mode. The changes seem reasonable and address the issue #401. The code is generally clear and well-structured.

Summary of Findings

• README update: The PR description mentions the need to update the README file to reflect the new API version configuration option. This is crucial for developers to understand how to use the new feature.

Merge Readiness

The code changes seem to be in good shape. However, it's important to update the README file as mentioned in the PR description before merging. I am unable to directly approve the pull request, and other reviewers should review and approve this code before merging.

[swastikCommits]

I have updated the README.md by adding a section called "Development Configuration".
Let me know if that needs any further changes.

[VaiTon]

@swastikCommits this is not what the issue was about. The api version is in general different from the product schema (we're at api v3 and product schema v 1001, see think link for details)

[swastikCommits]

Ah, thanks for correcting.
That means when a client makes a request with a specific API version, the server converts the response to match the corresponding product schema version.
So, we'll need to maintain the VITE_API_VERSION and add another parameter for SCHEMA_VERSION to handle SCHEMA_VERSION as we want. Currently, if we specify API v3.2 it will correspond to schema version 1001, so here the goal for us would be to access schema version 1000(which by default corresponds to v3.1) by still staying in the API version v3.2
@VaiTon correct me if I'm wrong.

[swastikCommits]

As I tested it locally and added parameters for both schema version and API version, but OFF API itself appears to have its own logic for determining which schema version to actually use in the response. This is likely internal API behaviour that we can't control.
We will need more discussions on it as of now, if I'm not wrong in my logic. Maybe we have to forcibly perform schema versioning in this use case. Please drop down your thoughts about this so that we can find out an approach to solve this.

[VaiTon]

@swastikCommits see the linked MD:

When a client makes a request with a specific API version, we do our best to convert the response to the corresponding product schema version.