-
Notifications
You must be signed in to change notification settings - Fork 15
use randomizationSeed instead of randomize boolean #76
Conversation
|
@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. |
|
Hrmm, doesn’t look like MongoDB actually supports providing your own random seed :( https://jira.mongodb.org/plugins/servlet/mobile#issue/SERVER-22225 |
|
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 |
|
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). |
|
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 |
There was a problem hiding this comment.
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
|
Yeah, I was thinking a mis-understanding from our side. I have two other ideas:
|
|
@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. |
|
Got it, thanks for the context @xtina-starr. let's go for it then. |
This changes support for randomization to use a
randomizationSeedthat 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: