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

[CI-3342] Pass section to getRecommendationPods #197

Merged
merged 7 commits into from
Apr 25, 2024

Conversation

VincentGalloro
Copy link
Contributor

Pass section to getRecommendationPods through parameters.

To maintain backwards compatibility, parameters will be treated as networkParameters in some cases. This is until all customers migrate to using both parameters.

@VincentGalloro VincentGalloro requested review from esezen, stanlp1 and a team April 18, 2024 16:21
@esezen esezen changed the title [CL 3342] Pass section to getRecommendationPods [CI-3342] Pass section to getRecommendationPods Apr 22, 2024
Copy link
Contributor

@stanlp1 stanlp1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes lgtm. Some small comments.

src/modules/catalog.js Show resolved Hide resolved
it('Should build requestURL with query params when parameters are passed', (done) => {
const { recommendations } = new ConstructorIO({
...validOptions,
fetch: async (reqUrl) => ({ ok: true, json: async () => reqUrl }),
Copy link
Contributor

@stanlp1 stanlp1 Apr 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thoughts on not overriding fetch here, actually sending a request?

While this is arguably better, closer to what a unit test should be, the rest of the tests all send requests, so I'm wondering if we should stick with that.

But tbh, doens't matter too much.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in this specific case I'm just trying to test that the request url gets built correctly, and not as concerned with the response. I can add an extra test that sends the request with these parameters for coverage

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think both approaches are fine but let's test the live request like Stanley mentioned. We can either

  1. Not override fetch and check both the request url and response in this test
  2. Leave this test as is and create a new test that's using actual fetch and hitting the API

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added the test 👍. I think it's good to have both just to make sure the parameter is getting added to the url as expected, at least while we have this hacky workaround with parameters/network parameters

@esezen esezen requested a review from stanlp1 April 24, 2024 21:47
Copy link
Contributor

@stanlp1 stanlp1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@esezen esezen merged commit 8296be5 into master Apr 25, 2024
8 checks passed
@esezen esezen deleted the cl-3342/get-recommendation-pods-pass-section branch April 25, 2024 14:10
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

Successfully merging this pull request may close these issues.

3 participants