5 of 6 standards met
While reading the Imperatively modifying linked fields (https://relay.dev/docs/guided-tour/updating-data/imperatively-modifying-linked-fields/) docs, I noticed that the fragment is defined as but spread as throughout the examples. If I understood correctly, Relay's fragment naming convention is (https://relay.dev/docs/guided-tour/rendering/fragments/). Since the component is named , the prefix should be rather than .
Repository: facebook/relay. Description: Relay is a JavaScript framework for building data-driven React applications. Stars: 18940, Forks: 1883. Primary language: Rust. Languages: Rust (53.3%), JavaScript (36.2%), MDX (8.8%), HTML (1%), CSS (0.4%). License: MIT. Homepage: https://relay.dev Latest release: v20.1.1 (7mo ago). Open PRs: 100, open issues: 715. Last activity: 23m ago. Community health: 75%. Top contributors: kassens, alunyov, captbaritone, tyao1, josephsavona, rbalicki2, yungsters, wincent, leebyron, SamChou19815 and others.
Last 12 weeks · 205 commits
Hey there! I have two conflicting Relay diagnostics when using with fragment colocation ## Setup: The conflict: Without : Relay LSP/compiler error — Expected 'items' to be passed a 'edges' selection With : ESLint relay/unused-fields error — This queries for the field 'edges' but this file does not seem to use it directly. If a different file needs this information that file should export a fragment and colocate the query for the data with the usage. The edges data IS colocated — in ChildList_connection via fragment spread. ParentContainer.tsx correctly delegates data usage to the child via Relay's fragment colocation pattern. The relay/unused-fields rule does not recognise that edges selected inside a field is used by the Relay runtime itself (for cursor-based pagination) and by a child fragment spread on the same connection object. Expected behavior: relay/unused-fields should suppress the warning for fields that are required by a directive in the same selection set, or should recognise child fragment spreads on the connection type as satisfying the usage requirement.
In order to work out what part of our very large schema is actually being used by our products, we've been exploring using the subschema extraction. Our intent is to identify dead / unused schema and make our breaking changes detection & test selection more fine-grained (specific to the consuming product) We've run into a problem of producing invalid schema. _schema_ _usage_ _output_ which is invalid, since has no fields. 1. We can't remove because it appears as an output type of and changing that would change the schema 2. We can't "fake" it with a dummy field because the Article would then need to implement that dummy field too 3. We can't use (which is effectively what happens at runtime) because is reserved This PR implements a "fix": If we find empty interfaces, we force their fields existence (and hence their implementing concrete types to have those fields). This means we do have "unused fields", but only for these cases. Not ideal, however this only occurs 12 times for us so is acceptable, and I expect it's not encountered in Meta's schema if it's not yet addressed.
Differential Revision: D90421387