Thanks to visit codestin.com
Credit goes to github.com

Skip to content
This repository was archived by the owner on May 18, 2022. It is now read-only.

Conversation

@xtina-starr
Copy link
Contributor

@xtina-starr xtina-starr commented Mar 1, 2019

This changes support for randomization to use a randomizationSeed that passes a unique string. This is to address the issue of the collections rail component getting updated with the same collection data despite being on different articles. This is caused because the way relay handles rendering component when the same parameters are passed.

ToDo:

  • Create a PR in metaphysics with schema changes.
  • Create a PR in reaction to sync the schema and use the updated parameter.

@peril-staging
Copy link
Contributor

peril-staging bot commented Mar 1, 2019

Warnings
⚠️ It looks like code was changed without adding anything to the Changelog.
You can add #trivial in the PR body to skip the check.

Generated by 🚫 dangerJS against f1aee7b

@alloy
Copy link

alloy commented Mar 2, 2019

@xtina-starr So did this fix the issue?

Also, as a side-note, currently kaws doesn’t actually do anything with the seed, but to complete the API the seed should actually be used in a way that results in the same set of collections being returned.

@alloy
Copy link

alloy commented Mar 2, 2019

Hrmm, doesn’t look like MongoDB actually supports providing your own random seed :( https://jira.mongodb.org/plugins/servlet/mobile#issue/SERVER-22225

@orta
Copy link
Contributor

orta commented Mar 2, 2019

It did fix the issue of duped sets of collections.

My gut take says the underlaying issue is still a mis-understanding of Relay's caching, but now that queries for each random collection are unique (because it has the string of the article it in) then all instances of the random collection don't get updated at the same time

@alloy
Copy link

alloy commented Mar 2, 2019

Ace 👌

I don’t think it’s a misunderstanding, I think it’s reasonable for Relay to assume that the graph is deterministic. I.e. the same input variables must refer to the same data set, so if that data changes in the store any live components that refer to it will get updated with the new data.

I wonder if there’s another way to influence that store “selector” (is what I think Relay calls it internally).

@l2succes
Copy link
Contributor

l2succes commented Mar 2, 2019

That makes sense, that was my assumption as well.

I was hoping there was a way with Relay to pass in an arbitrary (client-side only) parameter into a GraphQL query without actually changing the underlying schema since the seed is only being used to differentiate subsequent queries here.

@Arg("showOnEditorial", { nullable: true }) showOnEditorial: boolean,
@Arg("size", () => Int, { nullable: true }) size: number,
@Arg("randomize", { nullable: true }) randomize: boolean
@Arg("randomizationSeed", { nullable: true }) randomizationSeed: string
Copy link
Contributor

@l2succes l2succes Mar 2, 2019

Choose a reason for hiding this comment

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

In terms of the API, could we actually go with the following

collections(randomize: true, seed: "arbitrary_string") {
  id
}

as I think it makes the intent clearer to the consumer. We can also add a description to those arguments

e.g.

@Arg("randomize", () => Boolean, { nullable: true, description: "Returns a random sample of collection. Must specify size and seed" }) randomize: boolean

@orta
Copy link
Contributor

orta commented Mar 2, 2019

Yeah, I was thinking a mis-understanding from our side. I have two other ideas:

  • Adding extra (unused?) variables to the query from the client, but I'm willing to bet it won't get past the relay compiler.

  • I wondered if adding Node conformance to collections from Kaws would also fix the underlaying issue

@xtina-starr
Copy link
Contributor Author

@l2succes, I believe @alloy and I discussed passing the randomize boolean and seed and felt that randomizationSeed sort of self documents and prevents the need to pass or couple two arguments.

@xtina-starr
Copy link
Contributor Author

@l2succes @alloy @orta this blocks an A/B test that we are trying to get out today. Are there strong opinions against the existing implementation?

It's also worth noting that we can continue the conversation and use the closing of the test as an opportunity to implement whatever better solution we come up with. I just want to keep movement on this seeing that it's been held up for a while.

@peril-staging
Copy link
Contributor

peril-staging bot commented Mar 4, 2019

Warnings
⚠️ It looks like code was changed without adding anything to the Changelog.
You can add #trivial in the PR body to skip the check.

Generated by 🚫 dangerJS against f1aee7b

@l2succes
Copy link
Contributor

l2succes commented Mar 4, 2019

Got it, thanks for the context @xtina-starr. let's go for it then.

@l2succes l2succes merged commit b561dad into master Mar 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants