Update Compiler Playground tests #3927
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@captbaritone has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
zth
added a commit
to zth/relay
that referenced
this pull request
Aug 5, 2022
* Move QueryResource tests into OSS
Reviewed By: davidmccabe
Differential Revision: D36782871
fbshipit-source-id: aa9cb152a72a0e023cefa9149be93418a1a6c62a
* Move FragmentResources into our main test suite
Reviewed By: davidmccabe
Differential Revision: D36784412
fbshipit-source-id: 089d396c71264642c0d065f90e8cd7453837f3a6
* Move LiveResolvers test into OSS
Reviewed By: davidmccabe
Differential Revision: D36785201
fbshipit-source-id: 692a910db8e930e5a74d9546cd9fcaaa2513c4a7
* Move Client Edges to Client types tests
Reviewed By: davidmccabe
Differential Revision: D36788014
fbshipit-source-id: c2ade2460503d5ebfc785648be8556bced79a0a1
* Remove many unused deps
Reviewed By: ndmitchell
Differential Revision: D36811272
fbshipit-source-id: 7a9384d685b230c00ce250a37c91421f65c26b62
* Emit metadata for fragments w client edges
Summary:
Inspired by D36649352 (https://github.com/facebook/relay/commit/73f01accc7d5ea4cd241f86919d77b29d6c175aa) — useFragment() currently has to repeatedly check whether a given fragment result has missing client edges. In the new React Cache version of these hooks, this incurs an extra useEffect call. However, the majority of fragments won't have client edges — ideally we could completely avoid the runtime overhead for fragments that don't use this feature.
This diff changes the compiler to emit `hasClientEdges` metadata on fragments. A follow-up will change hooks to optimize based on this and avoid work for fragments that don't have any client edges.
Reviewed By: davidmccabe
Differential Revision: D36682923
fbshipit-source-id: b836640a9a6e716d5421ec61e8d57f1312505c84
* Update Compiler Playground tests (#3927)
Summary:
The compiler playground does not currently build due to the version of parkling_lot that we are using being incompatible with wasm-pack. I manually updated the parking_lot version to `0.12` in order to get it building again. This uncovered some tests which are currently failing. Updating these tests will make it easier to get the the compiler playground building again once we upgrade parking_lot officially.
Currently upgrading is somewhat complicated because we try to only have one version of each dependency installed at any given time in the Meta monorepo.
Pull Request resolved: https://github.com/facebook/relay/pull/3927
Reviewed By: josephsavona
Differential Revision: D36789186
Pulled By: captbaritone
fbshipit-source-id: 448502cdee3dd209c6f053e9cb236420e92dfc32
* Demonstrate duplicate field definition bug
Reviewed By: davidmccabe
Differential Revision: D36792818
fbshipit-source-id: be04278b0a432b9ec1ad5096c2999407ed321766
* Avoid creating duplicate field definitions
Reviewed By: davidmccabe
Differential Revision: D36793042
fbshipit-source-id: a01fd49db01a63606edad87dddda44714acf1b44
* Support CommonJS for @no_inline (#3923)
Summary:
The goal of this PR is to support `no_inline` in CommonJS, but I did a little clean up along the way.
We used to clone the `no_inline` directive to all of the FragmentSpreads that used that source fragment. That felt like a hack so I switched it over to use `NoInlineMetadata` which uses the cool and very hip associated data stuff.
Pull Request resolved: https://github.com/facebook/relay/pull/3923
Reviewed By: josephsavona
Differential Revision: D36820179
Pulled By: captbaritone
fbshipit-source-id: e69449410f4e06b0b213a59894cee96342eca049
* Optimize hooks based on client edge metadata
Summary: Uses the metadata added in the previous diff to avoid even looking for missing client edges for fragments that can never have them.
Reviewed By: davidmccabe
Differential Revision: D36684124
fbshipit-source-id: 7522b84676de6aefe9511827c0ec1b2539a22543
* Enable dependency injection of hook implementations
Summary:
Unrevert of D36492040 (https://github.com/facebook/relay/commit/b3381195c02c36d409ed328f952221496f8d1a95) which was reverted due to a Flow error (fixed/suppressed here) that for some reason didn't show up in Sandcastle or stop it from landing.
Allow the implementation of some hooks to be replaced -- to enable turning on via feature flag without increasing bundle size when off.
Reviewed By: josephsavona
Differential Revision: D36818964
fbshipit-source-id: 408797999dbfb1577a3842da7b7a71d24a8aa384
* Example of the error when resolvers used with different arguments
Reviewed By: captbaritone
Differential Revision: D36810021
fbshipit-source-id: 2fdc054e0e8c2f476fd6ff8f6819cb940b6781e2
* Example resolver without fragment used with different arguments in the query
Reviewed By: captbaritone
Differential Revision: D36810020
fbshipit-source-id: 441df8d6a850d894d27b9a23a403ab5b522c9e48
* Add LTI annotations to function params in xplat/js/RKJSModules/Libraries/Relay
Reviewed By: alunyov
Differential Revision: D36820258
fbshipit-source-id: b168ca1dd46df51b822e30c8fac50ecdad538e96
* Add LTI annotations to function params in xplat/js/RKJSModules/Libraries/Relay (tests)
Reviewed By: alunyov
Differential Revision: D36836715
fbshipit-source-id: 529cd9483c9376b009295ee3aeb450ab532b9163
* Regression test for D36706346
Reviewed By: alunyov
Differential Revision: D36823188
fbshipit-source-id: 5f3c33bf1dff01b371737669daaae57bb14f93c1
* Add fixture tests for hover
Summary:
Previously, it was not possible to make test assertions about how our hover code bahaved. This set of fixture tests should allow us to validate our hover behavior.
This should also make it possible for us to collect an overview of our existing hover behavior and potentially make it more consistent.
Reviewed By: alunyov
Differential Revision: D36854204
fbshipit-source-id: 36b94aa2ca42393a779a5a2c06e4d2f08fb51f85
* Deploy 0.179.0 to xplat
Reviewed By: gkz
Differential Revision: D36710466
fbshipit-source-id: 4dff0bf2f57d695abc183be9f89147f239fb4953
* Support query variables in `@inline` fragments (#3933)
Summary:
`[ERROR] ✖︎ Variables are not yet supported inside inline fragments.`
This PR will enable query variables to be used inside of `inline` fragments. I will work to get `argument` style variables working in a follow up PR. I'll try to outline what work I think is required to support fragment variables.
## Query Variables
Easy to turn on, I wrote a test to confirm that this works as expected.
## Fragment Variables with `arguments`
Not so easy, I'll try to layout what I found while diving deep.
### How `useFragment` works today
When reading the parent operation definition, fragment pointers are created. If the reader AST for that fragment has an `args` field (this comes from `argumentDefinitions`), the translated variables are inlined in the fragment pointer object.
When the useFragment for the fragment with `argumentDefinitions` is used, the variables from the parent's pointer are used in conjunction with the query's variables.
### What needs to change?
It seems like `InlineDataFragmentSpread` should have an `args` field in the reader AST. If we had that, we could temporarily swap out `this._variables` with the translated variables for the duration of `_createInlineDataOrResolverFragmentPointer` using `getArgumentValues`.
Pull Request resolved: https://github.com/facebook/relay/pull/3933
Reviewed By: alunyov
Differential Revision: D36828783
Pulled By: captbaritone
fbshipit-source-id: a60e33114bf44577f4c5fbd60d382c1d9e160ea1
* Enable enforce_local_inference_annotations in xplat/js/RKJSModules/Libraries/Relay (reapply)
Reviewed By: bradzacher
Differential Revision: D36875558
fbshipit-source-id: 822ebb808661cfbb2b385c1b15944259a16363da
* Avoid throwing when fragmentRef is null in plural case
Reviewed By: josephsavona
Differential Revision: D36362318
fbshipit-source-id: c3dfca2618efdf02133ad3d1223a79c34db86065
* autocargo
Reviewed By: zertosh
Differential Revision: D36881794
fbshipit-source-id: 44fe8805ed4588ea4c8092124543b9e117f22ba9
* Persist explorer state in the URL/local storage (#3930)
Summary:
This should allow the compiler explorer to be used as a mechanism for sharing minimal reproducible compiler bugs and other examples of compiler behavior.
The general idea is to consolidate all the state in the compiler explorer into a single object (Redux style):
* Schema
* Document
* Feature Flags
* Language
* Selected tab
And then (json) serialize and compress that state and persist it to the URL hash and local storage. Note that by using the URL hash we ensure the content of the explorer is never sent to the server, and thus the privacy of the content is improved.
Pull Request resolved: https://github.com/facebook/relay/pull/3930
Test Plan:
https://user-images.githubusercontent.com/162735/171328459-a675c8e5-a9a6-4a27-af2e-1230245b84d2.mov
**Static Docs Preview: relay**
|[Full Site](https://our.intern.facebook.com/intern/staticdocs/eph/1654205352/relay/)|
|**Modified Pages**|
**Static Docs Preview: relay**
|[Full Site](https://our.intern.facebook.com/intern/staticdocs/eph/D36845080/V3/relay/)|
|**Modified Pages**|
Reviewed By: alunyov
Differential Revision: D36845080
Pulled By: captbaritone
fbshipit-source-id: 532cdbed4e0b1014ff3232e1b8aa47dce16cafa1
* third-party/rust: Update async-trait from 0.1.52 to 0.1.56
Reviewed By: zertosh
Differential Revision: D36881793
fbshipit-source-id: ce9b86693dd18efa6884d29419970b41ebff5447
* Move test resolvers into relay-runtime package
Reviewed By: alunyov
Differential Revision: D36886101
fbshipit-source-id: e5cef7c6c351a16de805dcfb3c3cb3f75d7f2a5e
* Avoid useMemo for fragment data except on plurals
Summary: Micro-optimization to avoid an unnecessary `useMemo` call in the common case. Previously the new useFragmentInternal_REACT_CACHE() hook memoized the translation from internal hook to fragment result. However, for singular fragments this is a simple property lookup and isn't worth memoizing. Here, we exploit the fact that plurality is a static property of the fragment (doesn't change dynamically for a particular fragment invocation) and only memoize the computation for plural fragments.
Reviewed By: davidmccabe
Differential Revision: D36796332
fbshipit-source-id: 5651e62f9c2502f1a634cc825719e3fe4ed7fefd
* fix lints in OperationExecutor
Reviewed By: rbalicki2
Differential Revision: D36905286
fbshipit-source-id: 5b5e70f03cb1d57fe488911ea668eb743f327f25
* Make __typename selections within concrete linked fields have a string literal flowtype
Summary:
# What and why
* Currently, a selection like `foo { __typename }` will generate a type of `__typename: string`. We have never had a need to generate a more accurate type, hence we generate `string` instead of a string literal for the value of `__typename`.
* However, this is problematic for typesafe updaters! This requires assignments of `foo` to be validated, **even though we known statically that the validation can never fail**.
* With this change, assigning an array of linked fields is modified as follows:
```
const data = useFragment(graphql`fragment SourceFragment on User {
best_friends(count: 5) required(action: THROW) {
...Assignable_user
}
}`, userRef);
const env = useRelayEnvironment();
const onClick = () => {
env.commitUpdate(store => {
const {updatableData} = store.readUpdatableQuery(graphql`
query Updatable_best_friends updatable {
best_friends {
...Assignable_user
}
}
`, {});
// WE CAN REPLACE THIS
const validateUser = require('SourceFragment').validate;
const validBestFriends = data.best_friends.flatMap(bestFriend => {
const validBestFriend = validateUser(bestFriend);
if (validBestFriend !== false) {
return [validBestFriend];
} else {
// this case never occurs!
return [];
}
});
updatableData.best_friends = validBestFriends;
// WITH THIS
updatableData.best_friends = data.best_friends
});
}
```
# How
Pass around a `enclosing_concrete_linked_field_type: Option<Type>` through the codegen. Whenever we visit a linked field, we potentially pass `Some(linked_field_type)`. When we process a scalar field, if that parameter is Some, then we generate an AST with the StringLiteral of tha type.
# Rollout
This needs to rollout with a rollout. Once this diff is approved, I'll put a rollout in.
Reviewed By: alunyov
Differential Revision: D36357062
fbshipit-source-id: e06d076e6395183eb7872e47962c81e6cd4db475
* Preserve implicit dependencies
Reviewed By: tyao1
Differential Revision: D36909200
fbshipit-source-id: cde71524c1ff4357ca15ee896f80e11e781fe6a8
* Fix config (#3937)
Summary:
Hopefully we can make this config field optional. In the mean time, this should unbreak OSS CI.
Pull Request resolved: https://github.com/facebook/relay/pull/3937
Reviewed By: josephsavona
Differential Revision: D36912378
Pulled By: captbaritone
fbshipit-source-id: 89c072af53ec8cfb925b64be5dd30a3b09b070c3
* Summary:
This diff adds support for code/type generation for live relay resolvers without fragment.
- Removed validation for rootFragment in resolvers
- Live resolvers without a fragment now represented as inline fragment with single `__typename` selection. This should produce a valid server-only query (we still need add support for client-only queries), and we can adjust code/typegen to traverse into these inline fragment to generate `Relay Resolver` selections and types.
Reviewed By: captbaritone
Differential Revision: D36634250
fbshipit-source-id: c8d7dd0e3e2fb70c85071d9f7f8856c4bd21fcd0
* Generate resolver function types
Summary:
This diffs adds type generation for the resolver functions.
Next to the imported type of the resolver function we will generate an additional type assertion:
```
import myResolverFn from "myResolverFn"
(myResolverFn: (
rootKey: myResolverFnFragmentKey$key,
// we also generating flow-types for `args`.
) => mixed);
```
Now, if the resolver function doesn't match the generated type assertion there will be a flow error in the generated artifact.
- The bad thing about this: flow error in generated artifact may be confusing and not very clear on how to fix.
- The good thing about this: it will be impossible to flowfixme these types in generated artifacts.
Typescript is not implemented yet. But I suspect we can do something like this for TS:
https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABADwBQEMBOBzAXIgZykxjGwEp8wQBbAIwFNNEBvAKEU8UwahEyQAGANxsAvmzYAbXogD6 (https://github.com/facebook/relay/commit/4173a5e149a073d792dbed48d32ede2365ba7b3e)+DDiq1GmcogC8APkTowATy0pRQA
Reviewed By: captbaritone
Differential Revision: D36677395
fbshipit-source-id: 7ec7ca3a9bc888341766a076a7d0333c0ca39d6d
* remove inline fragment wrapper on the __typename for the resolvers without fragments
Reviewed By: captbaritone
Differential Revision: D36811839
fbshipit-source-id: 99011b370a9e1d8f16f69ae5e2e80d949de43281
* Example test with fragment-less in Live Resolver
Reviewed By: captbaritone
Differential Revision:
D36638884
LaMa Project: L1125415
fbshipit-source-id: 95357712ee8293386b6f26efbb69642b0adabeaf
* Test: Live resolver with args and no fragment
Reviewed By: captbaritone
Differential Revision:
D36678363
LaMa Project: L1125407
fbshipit-source-id: 8754f1f84782f04957c17b0f03be5ec3f806b201
* Disallow console errors/warns in fetchQuery test
Reviewed By: captbaritone
Differential Revision: D36896157
fbshipit-source-id: 1215325614e1679298dfa030a4375c6e53002dac
* Remove feature flag
Reviewed By: captbaritone
Differential Revision: D36921946
fbshipit-source-id: fc96a032f46d7e6ba388e90a6271c5923522c114
* Add PreloadedQuery import to render example (#3940)
Summary:
It's unclear as to where `PreloadedQuery` is coming from. Adding the import to make it clear.
Pull Request resolved: https://github.com/facebook/relay/pull/3940
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
**Static Docs Preview: relay**
|[Full Site](https://our.intern.facebook.com/intern/staticdocs/eph/D36937170/V2/relay/)|
|**Modified Pages**|
|[docs/guided-tour/rendering/queries](https://our.intern.facebook.com/intern/staticdocs/eph/D36937170/V2/relay/docs/guided-tour/rendering/queries/)|
Reviewed By: captbaritone
Differential Revision: D36937170
Pulled By: scottilee
fbshipit-source-id: 11dcbab348ce75cae72e3a10b5d56669dbd6c1fa
* Subscribe based on latest (missed) updates
Summary:
Updates the new React Cache version of `useFragmentInternal()` to handle edge cases in checking for missed updates. On commit (in useEffect), useFragment has to check for modifications to the store that occurred between when the hook read data and the time of commit and trigger a re-render. The previous version checked for changes to fragment *data* — triggering a re-render — but subscribed to the store using the stale snapshot created during render.
The edge case is that some changes to the store can affect *which* data should be subscribed to without changing the actual result of the fragment. In the new test case, the missed update changes a user's profile_picture object to point to a different record, but doesn't update the field (`uri`) that the fragment reads. Then, a subsequent update to the store updates the `uri` on the new profile_picture record. Previously useFragmentInternal would ignore this case since it subscribed to the old record; now it correctly updates.
Note that FragmentResource correctly handled this case, so this brings useFragmentInternal() up to parity.
*For a follow-up*, I realized while implementing this that are possibly other changes that can occur that may not be captured as changes to the result data. For example, it might be possible for a missing client edge to change as a result of a relationship change, without affecting the data (i'm not sure, have to double check). I added a todo for this since it needs more investigation and since FragmentResource also doesn't handle these cases.
Reviewed By: alunyov
Differential Revision: D36882905
fbshipit-source-id: 14e2c5a9bb702339bf198255d7a86ad8ad3d83fd
* Release provided variables feature (AKA: remove feature flag).
Reviewed By: tyao1
Differential Revision: D36949714
fbshipit-source-id: 82b22bc18f1bb5f05f1d9b1e6204d3e711d35816
* Support for client-only queries
Summary:
This diff removes restriction on client-only generation in Relay.
- This validation is removed from skip_unreachable_nodes and skip_client_extensions.
- The FlowTypes indicate the possibility of the text being `null`.
This change allows the building of complete client-only Relay applications, that may rely on Live Resolvers or imperative updaters APIs to write data to the Relay store.
Reviewed By: captbaritone
Differential Revision: D36890340
fbshipit-source-id: d52942f68aa1497d88d8d7326b3ddb24b3078bdc
* Test with client-only queries
Summary:
Set of tests with useLazyLoadQuery and client-only query.
- Render a query with data
- Render with missing data
- Update with `commitPayload`
- Update with `updatable`
- Throw network errors
Reviewed By: captbaritone
Differential Revision: D36935159
fbshipit-source-id: d1c5239a40cd76dd1d5fe078ea7ab7e2e3fa64bf
* Use `__id` field in relay resolver instead of `__typename`
Reviewed By: captbaritone
Differential Revision: D36904976
fbshipit-source-id: b328ae45780cc731edff52156f1c287395e335cd
* Generate client-only query types for client-only queries
Reviewed By: captbaritone
Differential Revision: D36922645
fbshipit-source-id: 90268b232b4e958dac68452ce40e865aa50ac489
* Fix flow error in ClientOnlyQueries-test in OSS
Reviewed By: captbaritone
Differential Revision: D36972668
fbshipit-source-id: 842fc7bc2b5c03eaf9bba7716850919139546111
* Bump eventsource from 1.1.0 to 1.1.1 in /website (#3934)
Summary:
Bumps [eventsource](https://github.com/EventSource/eventsource) from 1.1.0 to 1.1.1.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/EventSource/eventsource/blob/master/HISTORY.md">eventsource's changelog</a>.</em></p>
<blockquote>
<h1><a href="https://github.com/EventSource/eventsource/compare/v1.1.0...v1.1.1">1.1.1</a></h1>
<ul>
<li>Do not include authorization and cookie headers on redirect to different origin (<a href="https://github-redirect.dependabot.com/EventSource/eventsource/pull/273">https://github.com/facebook/relay/issues/273</a> Espen Hovlandsdal)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="https://github.com/EventSource/eventsource/commit/aa7a40843a978f42c0babdec125bf9e0a83bf515"><code>aa7a408</code></a> 1.1.1</li>
<li><a href="https://github.com/EventSource/eventsource/commit/56d489ef853a891deca121bbd463c732fee94dce"><code>56d489e</code></a> chore: rebuild polyfill</li>
<li><a href="https://github.com/EventSource/eventsource/commit/4a951e58b04118c9c4d3da3d27d454972a1b4b8d"><code>4a951e5</code></a> docs: update history for 1.1.1</li>
<li><a href="https://github.com/EventSource/eventsource/commit/f9f6416567bff62c1af2f4314be51d9870e94bc2"><code>f9f6416</code></a> fix: strip sensitive headers on redirect to different origin</li>
<li>See full diff in <a href="https://github.com/EventSource/eventsource/compare/v1.1.0...v1.1.1">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `dependabot rebase` will rebase this PR
- `dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `dependabot merge` will merge this PR after your CI passes on it
- `dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `dependabot cancel merge` will cancel a previously requested merge and block automerging
- `dependabot reopen` will reopen this PR if it is closed
- `dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/facebook/relay/network/alerts).
</details>
Pull Request resolved: https://github.com/facebook/relay/pull/3934
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
**Static Docs Preview: relay**
|[Full Site](https://our.intern.facebook.com/intern/staticdocs/eph/D36975527/V2/relay/)|
|**Modified Pages**|
Reviewed By: voideanvalue
Differential Revision: D36975527
Pulled By: alunyov
fbshipit-source-id: 01f5e0fc5926f4ccd86b44877c87a74a6b5caf3f
* Docs for v14
Reviewed By: voideanvalue
Differential Revision: D36975813
fbshipit-source-id: 196d1190da5d5a7270283fb3e2cc73edda3488eb
* v14.0.0
Reviewed By: voideanvalue
Differential Revision: D36975301
fbshipit-source-id: 3d168cf2ca31aacf7e2b1d0c4cd901548eeb9bb0
* Enable some ESLint rules which we use internally (#3944)
Summary:
This triggered on https://github.com/facebook/relay/pull/3935 when I imported it. Hoping to catch more of these things earlier (in the contributor's editor) rather than on import.
Pull Request resolved: https://github.com/facebook/relay/pull/3944
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
**Static Docs Preview: relay**
|[Full Site](https://our.intern.facebook.com/intern/staticdocs/eph/D36975762/V2/relay/)|
|**Modified Pages**|
Reviewed By: alunyov
Differential Revision: D36975762
Pulled By: captbaritone
fbshipit-source-id: 7dbd9d3ca7a2dc3ac016281e2a88ca69624caccf
* fix(compiler): make LocalPersister include trailing newline (#3938)
Summary:
We're seeing noise in our diffs because the LocalPersister does not include a trailing newline in its JSON output, but many editors append one automatically (for example, when people inspect the file):
<img width="418" alt="image" src="https://user-images.githubusercontent.com/7074/171994227-310aea2d-16ca-4da8-a1dd-e678bebb76ac.png">
Presumably, editors are doing this to be "helpful" because [POSIX defines a "line"](https://stackoverflow.com/a/729795/2103996) as (paraphrasing) "some or no non-newline stuff followed by a newline", but the unexpected diff output can be confusing for developers working in a large project — many of whom may not even know what persisted queries are.
This PR makes a small edit to append the newline automatically to Serde JSON's pretty output.
Pull Request resolved: https://github.com/facebook/relay/pull/3938
Reviewed By: alunyov
Differential Revision: D36937182
Pulled By: captbaritone
fbshipit-source-id: 14341811f1885fa2750d1b18576f06b783ea88fa
* Re-sync with internal repository (#3952)
Co-authored-by: Facebook Community Bot <6422482+facebook-github-bot@users.noreply.github.com>
* Update Cargo.lock (#3951)
Summary: Pull Request resolved: https://github.com/facebook/relay/pull/3951
Reviewed By: voideanvalue
Differential Revision: D36985025
Pulled By: alunyov
fbshipit-source-id: 99663d788263c310552a9dddff6dd0529e5f26e6
* Validate rust fmt in GtiHub CI (#3950)
Summary:
I plan to rebase this on top of another diff that will add a truely synced version of our rustfmt config, but I wanted to test this in the mean time.
Pull Request resolved: https://github.com/facebook/relay/pull/3950
Test Plan: See screenshots in GitHub PR
Reviewed By: voideanvalue
Differential Revision: D36986167
Pulled By: captbaritone
fbshipit-source-id: 2d5c7ed8aacb2830fc5a3185933753a5e9d889a6
* Small refactoring in the `skip_unreachable_nodes` - store errors in the ValidationMode::Strict
Reviewed By: captbaritone
Differential Revision: D36973133
fbshipit-source-id: 8e449c48c8e2321b2dd841ba7fdfc344bf3d5bd0
* Include platform and arch in the compiler error message
Reviewed By: voideanvalue
Differential Revision: D36975241
fbshipit-source-id: 5ac6b9e8d072f940cb6c403299f4f7b79454a009
* Fix to always render w latest state
Summary:
Fixes the new Cache-friendly `useFragment()` implementation to handle the case of props changing to point to a different entity. The use-case is:
* Render user 1. This subscribes for updates on that user.
* In a batch, delete user 1 and enqueue an update to render user 2 instead.
* This should avoid incorrectly attempting to render the (deleted) user 1.
Currently we render once w the stale data and then render again with the correct data. This is now fixed: in addition to enqueuing a setState when the entity changes we also eagerly render w the new entity. Due to useFragmentInternal()'s use of state we can't avoid a double render in this case, but we can avoid rendering the stale data.
Reviewed By: davidmccabe
Differential Revision: D36956052
fbshipit-source-id: 9e54a8de7c2358cb35fa9f39ba2848dae1e9dfdf
* Unify Prettier config and enforce Prettier in GitHub CI (#3953)
Summary:
This PR starts with an intentional error to confirm that it reports errors in CI.
Pull Request resolved: https://github.com/facebook/relay/pull/3953
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
**Static Docs Preview: relay**
|[Full Site](https://our.intern.facebook.com/intern/staticdocs/eph/D36989721/V2/relay/)|
|**Modified Pages**|
Reviewed By: josephsavona
Differential Revision: D36989721
Pulled By: captbaritone
fbshipit-source-id: 87acb3726eba88fb8a438ccae8f6d0f5553e522c
* Add a script that runs the compiler from Cargo without any config (#3956)
Summary:
While working on our tests, I always want LSP support and to have the Relay compiler open in watch mode automatically. With this script (and tbezman's VSCode plugin) we can have that!
Here's the VSCode project settings.json file I'm using:
```
{
"typescript.validate.enable": false,
"javascript.validate.enable": false,
"relay.pathToConfig": "./scripts/config.tests.json",
"relay.pathToRelay": "./scripts/dev-compiler.sh",
"relay.autoStartCompiler": true,
}
```
Using the LSP in our tests (with the compiler auto starting in watch mode):
https://user-images.githubusercontent.com/162735/172533113-d2fdfbb4-d3f6-405c-af09-b519d612e7fa.mov
Pull Request resolved: https://github.com/facebook/relay/pull/3956
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
**Static Docs Preview: relay**
|[Full Site](https://our.intern.facebook.com/intern/staticdocs/eph/D37005582/V2/relay/)|
|**Modified Pages**|
Reviewed By: alunyov
Differential Revision: D37005582
Pulled By: captbaritone
fbshipit-source-id: 9effe5e87dae6f34a8e9e4c59e4144ec42587972
* Use WeakMap for query caches
Summary: QueryResource uses WeakMap (if available) to store the per-environment query caches, in order to avoid leaking memory (note that some parts of the UI create disposable environment instances for a preview). This diff updates `getQueryResultOrFetchQuery()`, the Cache equivalent to QueryResource, to similarly use WeakMap if available.
Reviewed By: alunyov
Differential Revision: D37009628
fbshipit-source-id: a9346e9ba1263da301471f19b12c59494ce1a5e1
* Flow: Ignore nested node_modules (#3955)
Summary:
Without these, if I build the website locally and then try to run Flow, I get the following error:
<img width="863" alt="Screen Shot 2022-06-07 at 9 18 52 PM" src="https://user-images.githubusercontent.com/162735/172530647-a589f872-1565-4a48-83c2-259ba097c818.png">
Pull Request resolved: https://github.com/facebook/relay/pull/3955
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
**Static Docs Preview: relay**
|[Full Site](https://our.intern.facebook.com/intern/staticdocs/eph/D37005584/V5/relay/)|
|**Modified Pages**|
**Static Docs Preview: relay**
|[Full Site](https://our.intern.facebook.com/intern/staticdocs/eph/D37005584/V5/relay/)|
|**Modified Pages**|
Reviewed By: josephsavona
Differential Revision: D37005584
Pulled By: captbaritone
fbshipit-source-id: bf2e603c109b283febdc6dc6f0d0fb246c1baa98
* Document LSP
Reviewed By: alunyov
Differential Revision: D37014626
fbshipit-source-id: 4c5ae87ff53e6f5860c895f748d02bac2cfd2f60
* VS Code Extension - update compiler SEMVER_RANGE
Summary: Fix: https://github.com/facebook/relay/issues/3957
Reviewed By: captbaritone
Differential Revision: D37017044
fbshipit-source-id: b2768fcbae9d73cb81beb704a911f22d753d2d63
* Provide a good VSCode setup for contributors (#3959)
Summary:
Knowing all the extensions and settings you should have in order to be an effective contributor takes a ton of effort. These should help people be more effective right away.
tbezman any recommendations that I've missed?
Pull Request resolved: https://github.com/facebook/relay/pull/3959
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
**Static Docs Preview: relay**
|[Full Site](https://our.intern.facebook.com/intern/staticdocs/eph/D37029826/V2/relay/)|
|**Modified Pages**|
Reviewed By: josephsavona
Differential Revision: D37029826
Pulled By: captbaritone
fbshipit-source-id: 6f834c036bf677596f4f8328fe499bf938032fcc
* Support @live resolver with client edge and no fragment (#3942)
Summary:
Running `./scripts/compile-tests.sh` results in a compiler panic:
```
╭─[00:00]: captbaritone at moffo in ~/projects/relay on branch*
╰─➤ ./scripts/compile-tests.sh
warning: /Users/captbaritone/projects/relay/compiler/crates/relay-compiler/Cargo.toml: version requirement `0.11.1+zstd.1.5.2` for dependency `zstd` includes semver metadata which will be ignored, removing the metadata is recommended to avoid confusion
Finished release [optimized] target(s) in 0.08s
Running `target/release/relay /Users/captbaritone/projects/relay/scripts/config.tests.json`
[INFO] querying files to compile...
[INFO] [tests] compiling...
thread 'tokio-runtime-worker' panicked at 'Expected Client Edge backing field to be a fragment spread representing a Relay Resolver. ScalarField {
alias: None,
definition: WithLocation {
location: <generated>:0:0,
item: FieldID(559),
},
arguments: [],
directives: [
Directive {
name: WithLocation {
location: <generated>:0:0,
item: "__RelayResolverMetadata",
},
arguments: [],
data: Some(
RelayResolverMetadata {
field_parent_type: "Query",
import_path: "packages/relay-runtime/store/__tests__/resolvers/LiveConstantClientEdgeResolver.js",
field_name: "live_constant_client_edge",
field_alias: None,
field_path: "live_constant_client_edge",
field_arguments: [],
live: true,
},
),
},
Directive {
name: WithLocation {
location: packages/react-relay/__tests__/LiveResolvers-test.js:70:80,
item: "waterfall",
},
arguments: [],
data: None,
},
],
}', crates/relay-codegen/src/build_ast.rs:1040:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[ERROR] A thread that the Relay compiler spun up did not shut down gracefully: panic
[ERROR] Compilation failed.
[ERROR] Unable to run relay compiler. Error details:
A thread that the Relay compiler spun up did not shut down gracefully: panic
```
Pull Request resolved: https://github.com/facebook/relay/pull/3942
Reviewed By: josephsavona
Differential Revision: D36985529
Pulled By: captbaritone
fbshipit-source-id: 659845ea725483d4eea655b0219ab28d4fc59960
* Remove state / raw-state distinction
Summary: The raw-state / state distinction is no longer useful after other recent changes, and it can break memoization in some cases since the state object changes. Let's remove this distinction.
Reviewed By: davidmccabe
Differential Revision: D36987134
fbshipit-source-id: 679a764b39a49881aaf5a92e3486c0b8cc3e24c1
* theoretical edge case for batched state changes
Summary:
Fixes a *theoretical* issue that can occur when different types of state updates are batched. When enqueuing a setState due to a change in data, useFragmentInternal now checks to see if the current state's selector has changed. If so, it bails out of the state update.
It's *really* hard to construct a unit tests for this case since it requires triggering a relay data change at precisely the right time relative to React's operation. However it seems safer to add this logic than not to, so i'm inclined to ship this w/o a test. Open to feedback here.
Reviewed By: davidmccabe
Differential Revision: D36988439
fbshipit-source-id: 648870657599d205c1de72f5c021a9078a6400c5
* Resolvers without fragments don't have dependencies (#3954)
Summary:
Previously we would mark a resolver as having a dependency on the parent record. If the parent record was updated, would invalidate the resolver.
On a subsequent render, we would check the resolver's validity, and trigger a warning here: https://github.com/facebook/relay/blob/baa2e6d728672b59e31ffc564a89c7be960aa7e9/packages/relay-runtime/store/experimental-live-resolvers/LiveResolverCache.js#L405
Pull Request resolved: https://github.com/facebook/relay/pull/3954
Reviewed By: alunyov
Differential Revision: D37005589
Pulled By: captbaritone
fbshipit-source-id: b37ab250b03428ae2a1b31267e43e4d5ee7648cd
* Revert D37005589: Resolvers without fragments don't have dependencies
Differential Revision:
D37005589 (https://github.com/facebook/relay/commit/8147d170e67d252852c4a1d469ee35d93c701d8f)
Original commit changeset: b37ab250b034
Original Phabricator Diff: D37005589 (https://github.com/facebook/relay/commit/8147d170e67d252852c4a1d469ee35d93c701d8f)
fbshipit-source-id: a80669de8028bcfdebcb83366dddafdc89f8f5e8
* Mark release
Reviewed By: alunyov
Differential Revision: D37029870
fbshipit-source-id: e60595a93da5fd185b2c1cd24dae07ed041ec99d
* Publish Relay VS Code extension from Github Actions (#3963)
Summary:
With this change we will be able to publish new extension version from Github. No need to have a local setup for the extension.
Pull Request resolved: https://github.com/facebook/relay/pull/3963
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
**Static Docs Preview: relay**
|[Full Site](https://our.intern.facebook.com/intern/staticdocs/eph/D37040268/V3/relay/)|
|**Modified Pages**|
Reviewed By: rbalicki2
Differential Revision: D37040268
Pulled By: alunyov
fbshipit-source-id: e8abb0cb4fe7d8cee8ddbe13a20d4f561a21fffd
* Update docs now that validators are rarely required
Summary: * Since the __typename changes rolled out, we no longer need validators for most linked field assignments! Woohoo!
Reviewed By: alunyov
Differential Revision: D37011761
fbshipit-source-id: 833ef0c8e0c474631d310dc0b1c1155061844552
* Use `yarn` in the vscode action for extension release (#3964)
Summary: Pull Request resolved: https://github.com/facebook/relay/pull/3964
Reviewed By: josephsavona, captbaritone
Differential Revision: D37045995
Pulled By: alunyov
fbshipit-source-id: 5ea2befd069b8412c8e516c1218dbb36cc552f27
* Set custom scalars values via typesafe updaters
Reviewed By: josephsavona
Differential Revision: D37044950
fbshipit-source-id: 608573d51e7f90b6c563cc31af6b000188d2a16a
* Back out "Revert D37005589: [relay][PR] Resolvers without fragments don't have dependencies"
Reviewed By: josephsavona
Differential Revision: D37049077
fbshipit-source-id: a3447ac0ca480c70f5f956e936c02d4d6e2bafd8
* docs: Update search term in Relay for VSCode docs (#3962)
Summary:
The search term "Relay for VSCode" doesn't show the extension "Relay GraphQL".
| Relay for VSCode | Relay GraphQL |
| --- | --- |
| <img width="354" alt="Screenshot 2022-06-09 at 12 50 40" src="https://user-images.githubusercontent.com/4691889/172830255-9f8ab843-a5c0-4bcf-8bbb-8a0594a697c1.png"> | <img width="354" alt="Screenshot 2022-06-09 at 12 50 04" src="https://user-images.githubusercontent.com/4691889/172830151-fff2fccf-91df-443e-83ce-4e87a2eda773.png">|
Pull Request resolved: https://github.com/facebook/relay/pull/3962
Reviewed By: alunyov
Differential Revision: D37061868
Pulled By: captbaritone
fbshipit-source-id: e2f2254ab622f2510eb0dc9c4b810b4b89f9cfac
* Remove note on Haste requirement for resolvers (#3967)
Summary:
I tried this out (with a CommonJS-based project) and it works fine!
The generated query resolver correctly `require`s based on the relative path:
```
...
"kind": "RelayResolver",
"name": "greeting",
"resolverModule": require('./../user/UserGreetingResolver.js'),
"path": "viewer.greeting"
...
```
And it works at runtime
Not entirely sure if I'm modifying the docs in the right place
Pull Request resolved: https://github.com/facebook/relay/pull/3967
Reviewed By: alunyov
Differential Revision: D37072653
Pulled By: captbaritone
fbshipit-source-id: 5bfa51cb43fe3cdc62394195dd9c78c2ca4387a7
* Add debugging guide for undersanding why fields might be null
Reviewed By: alunyov
Differential Revision: D37046829
fbshipit-source-id: ac997531b6f3fec6d30a866196484e6afe665f12
* Deploy 0.180.0 to xplat
Reviewed By: gkz
Differential Revision: D37075801
fbshipit-source-id: 2e5eef84b4dde7fe789d7506a32dbbaeb7ae3b8f
* Improve name for Client Edge stripping transforms
Reviewed By: josephsavona
Differential Revision: D37086659
fbshipit-source-id: 8d865e06a8c321dfd553e57bee417089cacbaca4
* Add test with conflicting client fields
Summary: Add a test-case that demonstrates a bug in the relay-compiler where we do not validate conflicts in client fields.
Reviewed By: tyao1
Differential Revision: D37069157
fbshipit-source-id: 2e3210abd9ea1cecbde7acfeb8761aa715a330b1
* Validate conflicting selections in client fields
Summary: Moving the `validate_selection_conflict` before we are skipping the client extensions correctly validates conflicts in the client-only fields.
Reviewed By: tyao1
Differential Revision: D37069206
fbshipit-source-id: e56349fa2a39047b38031722799d8522262d4f7b
* Support custom scalar arguments that are passed as literals
Summary:
Fix: https://github.com/facebook/relay/issues/3730
Relay V12 used to support custom scalars arguments, that are passed as literal values:
See the generated output:
https://github.com/christianvuerings/relay-v13-argument-scalars/blob/53c22333a486d3f69033a205952739920d9fb184/relay-v12/src/__generated__/RootQuery.graphql.js#L103
In v12 this works not only for string literals, but for other types, including complex types.
This diff adds support for these string literals in the new compiler.
Reviewed By: josephsavona
Differential Revision: D37068556
fbshipit-source-id: 71f1aaff15389b307b373b62bcb2ecb77acab8c4
* Adds language option to relay.config.js (#3973)
Summary:
Update relay config step in installation docs
Pull Request resolved: https://github.com/facebook/relay/pull/3973
Reviewed By: josephsavona
Differential Revision: D37117258
Pulled By: alunyov
fbshipit-source-id: e94151090805f602f899e5bce696aa940fc2163d
* Correctly remove RefetchableFragment artifacts for ClientEdges in incremental mode.
Summary:
The root cause of the issue was an incorrect artifact mapping from the source to the generated artifacts for a fragment.
For `RefetchableFragments` generated for client-edge queries the source was the name of the virtually created fragment, where we should be using the original "client-edge" fragment spread source.
Interestingly, we already have a special case for these client-edge generated fragments, where their source hash (see the directive CLIENT_EDGE_GENERATED_FRAGMENT_KEY) was generated for the "client-edge".
This diff also passes this `source_name` to the reader's `source_definition_names`, which later will be used in the compiler's artifact map to correctly attribute generated artifacts to their source fragments.
Reviewed By: josephsavona
Differential Revision: D37116613
fbshipit-source-id: 3bccc96a5358dd53ab8f114407e07239f37a56c5
* Add support for resolvers without fragments
Summary:
Remove validation for `rootFragment` on the resolver definition.
- With this we can expose plain functions as GraphQL fields
- With this we can extend object with client fields that may return Client or Server Objects.
Reviewed By: josephsavona
Differential Revision: D37119681
fbshipit-source-id: 203fd3e99d68096532b9eb3e45f661766da2402a
* Skip null arguments before validating selection conflicts
Summary: Move `skip_null_arguments_transform` before validating selection conflicts, to resolve not-conflicting selections that may have literal `nulls` as arguments.
Reviewed By: josephsavona
Differential Revision: D37119312
fbshipit-source-id: 496881b36038db36452b1272cbce99590c71dc33
* Add `langugage` to the v14 docs
Summary: Update the docs
Reviewed By: captbaritone
Differential Revision: D37139659
fbshipit-source-id: 53dfef7f0b84ddfc7df2ea036e1db7f62f99cbf0
* Demonstrate client edges getting swallowed
Reviewed By: alunyov
Differential Revision: D37112971
fbshipit-source-id: 7dde52800458ba5f23e2af4c68d5035cf32aa17a
* Clarify fetchQuery subscription
Reviewed By: josephsavona
Differential Revision: D31999273
fbshipit-source-id: fad71d4b0254f20c080739106bfe8f6489a9a94a
* VSCode extension pathToRelay doesn't allow relative paths (#3969)
Summary:
This PR is an attempt at allowing the `pathToRelay` configuration option in VSCode to have relative paths. When this happens, the path will be resolved relative to the `rootPath`.
This is to support shared settings across many developers in the same workspace, while also having a custom compiler instead of the default one coming from the relay-compiler package. Because the extension currently doesn't allow `pathToRelay` to be relative, this would mean that each developer in our repository would need a different value for this setting.
I'm not too familiar with how VSCode extensions or the LSP client works, so I'm sorry in advance if the change I'm proposing doesn't make sense. Happy to follow up with improvements based on your feedback.
I'm not sure why the `LanguageClient` doesn't allow a relative path in `serverOptions.command`, so what I did was convert that to an absolute path by leveraging `path.resolve` and using the `rootPath` value from context. I tried this in my setup, with the extension installed in my VSCode and it works as expected.
Pull Request resolved: https://github.com/facebook/relay/pull/3969
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
**Static Docs Preview: relay**
|[Full Site](https://our.intern.facebook.com/intern/staticdocs/eph/D37145066/V2/relay/)|
|**Modified Pages**|
Reviewed By: alunyov
Differential Revision: D37145066
Pulled By: captbaritone
fbshipit-source-id: 16e8af546b4970c10416ba21d6964f3529443e1c
* Disallow default values on resolver fields
Summary: We don't currently support default values on the resolver fields. Let's disable these for now, and we will figure how to enable them, when we need them.
Reviewed By: captbaritone
Differential Revision: D37155226
fbshipit-source-id: 59eaf2681b91becc360f9ea143b1d8133facdf86
* Optimize validate_selection_conflict hashmaps
Reviewed By: alunyov
Differential Revision: D37177046
fbshipit-source-id: 42e615df5fff7b7e734f0c1572992651538572d6
* Cut minor release
Reviewed By: alunyov
Differential Revision: D37178961
fbshipit-source-id: db6bc569741c7be686c609993202e062ded2edc5
* Prep useRefetchableFragment test for multiple versions
Summary:
Refactors useRefetchableFragmentNode-test to prepare for the next diff in this stack where we test both the old and new implementation of useRefetchableFragment. Major changes:
* Asserts the data that is *committed* as opposed to what is rendered, this makes the test agnostic of the number of renders within each batch (important since the impls differ slightly in this regard).
* Changes to `describe.each()` but with a single implementation. This changes the formatting of the test but doesn't actually test anything different.
Reviewed By: davidmccabe
Differential Revision: D37145500
fbshipit-source-id: 80683970d17f06a1187b2d6e2f9f7798c60c64ff
* Use QueryResource, implement useRefetchableFragment
Summary:
This bundles a few changes together, i'm happy to split them up though:
* Changes `useFragmentInternal()` to use QueryResource instead of the new getQueryResultOrFetchQuery() hook. This allows us to decouple the safer, more impactful part of the refactor (avoiding FragmentResource) from the higher-risk portion of the refactor.
* Adds a `readFragmentInternal()` hook that implements the logic to read a fragment from the store, it's basically `useFragmentInternal()` but stateless and wo using any hooks. This is necessary since it's called conditionally in useRefetchableFragment.
* Implements the "cache" version of `useRefetchableFragment()`, using QueryResource for fetching but useFragmentInternal and readFragmentInternal for dealing w fragment data.
* Updates the useRefetchableFragment unit tests to test both versions, notably this required changing to test what data is *committed* rather than what data is rendered (since the new version may render more often, even if those renders are batched).
Reviewed By: davidmccabe
Differential Revision: D37058387
fbshipit-source-id: 94884c550e8c2b72655d68d760a68369760bfae8
* useClientQuery hook
Summary:
Based on the discussion here: https://github.com/facebook/relay/issues/3760#issuecomment-1156285034
This diff adds a new hook, that is meant to be used to render client-only queries. We're doing this to be intentional about our APIs. We want to make sure that client-only queries cannot be used with the API that can send a network request. In general, `FetchFn` with client-only query will throw, if request does not have a persisted query ID or a query text.
Implementation:
This hook is a just `useLazyLoadQuery` hook with `store-only` fetch policy.
The flow should enforce that client-only queries are used with the correct hook (ClientQuery type is removed for `useLazyLoadQuery`).
Reviewed By: josephsavona
Differential Revision: D37171439
fbshipit-source-id: 970664a025b361805aaff8fc39270d8c2f4ba837
* Upgrade clap to 3.1.18
Reviewed By: zertosh
Differential Revision: D37142007
fbshipit-source-id: 7a948c91a25919e6ba8a8706a19827658d168a2a
* Fix typo in code example (#3976)
Summary: Pull Request resolved: https://github.com/facebook/relay/pull/3976
Reviewed By: rbalicki2
Differential Revision: D37208861
Pulled By: alunyov
fbshipit-source-id: bcc6841fc51df5ad29165f5a8d8590bd73f74795
* switch from babel-eslint to hermes-eslint for flow code
Reviewed By: motiz88
Differential Revision: D37181192
fbshipit-source-id: 1f59e01f306792e67a4977435c5c77e0000d960a
* non-FragmentResource version of usePaginationFragment
Summary:
Implements a new version of `usePaginationFragment()` backed by the new `useFragmentInternal()` and `useRefetchableFragmentInternal()`. The majority of the work here is reworking the unit test for this hook to test both environments. I ran into what I believe is a Jest bug related to `doMock()`, where for some reason the `unsubscribe` mock function identity was getting lost, and assertions about the number of unsubscribes were failing despite the function clearly being called the right number of times (confirmed with logging). I also got different results with `fit()` to isolate tests, where they would pass when focused but not when run with all tests. Given that these same tests worked before switching to describe.each, and i didn't change anything else substantial about the file (at that point), it makes me suspicious of a Jest bug.
The use of the mock environment, and doMock generally, has always been a code smell though, so i refactored the test to use a normal environment instance and only mock the network layer.
Reviewed By: davidmccabe
Differential Revision: D37125130
fbshipit-source-id: 25e9b47d72f6d3631b6da7c5242df8017ad12e94
* Fix prettier config in VSCode Extension (#3971)
Summary:
Some of the config brought over in https://github.com/facebook/relay/issues/3953 borked some stuff.
I "fixed" the config and re ran prettier against the files.
Pull Request resolved: https://github.com/facebook/relay/pull/3971
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
**Static Docs Preview: relay**
|[Full Site](https://our.intern.facebook.com/intern/staticdocs/eph/D37144915/V2/relay/)|
|**Modified Pages**|
**Static Docs Preview: relay**
|[Full Site](https://our.intern.facebook.com/intern/staticdocs/eph/D37144915/V4/relay/)|
|**Modified Pages**|
Reviewed By: alunyov
Differential Revision: D37144915
Pulled By: captbaritone
fbshipit-source-id: 05c227d712e89c0ba5f14dabc08fc7a1cf047c38
* Ensure Client Edges Metadata inline fragments don't get merged in flatten transform
Reviewed By: alunyov
Differential Revision: D37194903
fbshipit-source-id: b6f6e0074e3e0332d5aabdc3d4799af60d3f7c81
* Injectable usePaginationFragment and useRefetchableFragment
Summary:
Add pagination fragment and refetchable to the injectable hooks where we can feature flag the implementation.
Removes implementation detail from the exported type of usePaginationFragment.
Reviewed By: josephsavona
Differential Revision: D37215553
fbshipit-source-id: 4332005cc982b76b13d9adea70a8719789532c96
* Fix typos in the required directive guide
Reviewed By: captbaritone
Differential Revision: D37197740
fbshipit-source-id: d15114034d4c083f997e0963effc993d844f5a4c
* Explicitly enumerate unsupported ReaderNode types
Reviewed By: rbalicki2
Differential Revision: D37226818
fbshipit-source-id: 65bc6b4520f7f9a8dc35a763bc051cc717fac292
* add exact_by_default=true to .flowconfig (#3980)
Summary:
matching `.flowconfig` option used in dev env setups internally at Meta where we sync relay into
Pull Request resolved: https://github.com/facebook/relay/pull/3980
Reviewed By: captbaritone
Differential Revision: D37246522
Pulled By: voideanvalue
fbshipit-source-id: 41e4052e0c14c660fd9c3116a2eb68a928716120
* Update Flow types for Jest (#3979)
Summary:
Internally, in the monorepo, our flow types for Jest come from https://github.com/facebook/react-native/blob/main/flow/jest.js
This copies that file over here into our OSS types. I had to make a few
superficial changes to appease our lint rules, but this is just a copy of the
typed from React Native's repo.
Pull Request resolved: https://github.com/facebook/relay/pull/3979
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
**Static Docs Preview: relay**
|[Full Site](https://our.intern.facebook.com/intern/staticdocs/eph/D37245951/V2/relay/)|
|**Modified Pages**|
Reviewed By: voideanvalue
Differential Revision: D37245951
Pulled By: captbaritone
fbshipit-source-id: f8aa9f9c26deabca74e1349309f63c6adbae214e
* Deinjectify useLazyLoadQuery
Reviewed By: josephsavona
Differential Revision: D37252240
fbshipit-source-id: 20b64ffb3322bd35c8911e0ae40ce672fa8ee784
* Further Performance optimizations
Reviewed By: josephsavona
Differential Revision: D37188823
fbshipit-source-id: 210a029e03f8be839fce61a66c6b58564003a591
* Import type for resolver function in client edges
Summary:
Our typegen for client-edges was not generating import types for resolver fields. This was happening because we were removing the resolver filed for the client-edges in the typegen - to generate the correct selection type for the client-edge reader.
But we need both - client-edge selection for the reader, and also the resolver field - to import resolver function type assertion.
This diff:
- in the apply_transforms for typegen we will keep the client-edge fields unchanged.
- in the typegen visitor we need a special handling client-edges. For inline fragments with client-edge directive we will generate import type for their resolver function. And we will traverse into their fragment selections to keep reader types correct.
Reviewed By: captbaritone
Differential Revision: D37211218
fbshipit-source-id: 729fec25d85bc007e7c35c47ab28bf25cffd04cd
* Generate LiveState<...> return type for live resolvers
Summary: This diff adds a return type `LiveState<any>` to these live resolvers. Using `any` is fine here, as we not really accessing this type. This assertion is needed to make sure the resolver function follows the expected interface of live resolvers.
Reviewed By: captbaritone
Differential Revision: D37218710
fbshipit-source-id: 553d8314bb178a32f19a38a91e1a2e9d70eadc73
* Revert D37188823: Multisect successfully blamed D37188823 for test or build failures
Reviewed By: voideanvalue
Differential Revision: D37305597
fbshipit-source-id: 9ffbbf78c1f020b2223e4849a542788459238d45
* codemod away flow exact object type syntax (#3981)
Summary:
Don't need these anymore after https://github.com/facebook/relay/issues/3980
Pull Request resolved: https://github.com/facebook/relay/pull/3981
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
**Static Docs Preview: relay**
|[Full Site](https://our.intern.facebook.com/intern/staticdocs/eph/D37248900/V2/relay/)|
|**Modified Pages**|
Reviewed By: alunyov
Differential Revision: D37248900
Pulled By: voideanvalue
fbshipit-source-id: 43359cd883850f6b100638bb1480719367911e0b
* extra suppression for www sync
Summary: D37245411 (sync diff) failed on www because of a difference in Flow version or config, one suppression comment in usePaginationFragment-test should have been enough but www complained. To unblock i added this extra suppression locally, this diff is to follow-up and add it back to the original file.
Reviewed By: voideanvalue
Differential Revision: D37294519
fbshipit-source-id: 84e9358a6ddda5ad55c155a2a79b37cb17eddfae
* Make artifact.path available to OperationPersister
Summary: Plumb the `artifact.path` into the `OperationPersister` to support emitting that path with persisted artifact hashes—allowing analysis tools to give sharper feedback.
Reviewed By: alunyov
Differential Revision: D37120669
fbshipit-source-id: 91300f34aff458aec9b0da63ee54b2ac863eecc2
* Deploy 0.180.1 to xplat
Reviewed By: SamChou19815
Differential Revision: D37313175
fbshipit-source-id: 3a8507a4914bcafb1ec84ed260d67cd28bba9169
* Back out **AND FIX** "Revert D37188823: Multisect successfully blamed D37188823 for test or build failures"
Reviewed By: tyao1
Differential Revision: D37313749
fbshipit-source-id: 530d6b282e996ced6a8032d17f55a3eb98530a51
* Deinjectify usePreloadedQuery
Reviewed By: josephsavona
Differential Revision: D37296050
fbshipit-source-id: 1dd90437b7a0bc11d074dddd7d203f4e069ba0b2
* Fix typo in the example (#3982)
Summary: Pull Request resolved: https://github.com/facebook/relay/pull/3982
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
**Static Docs Preview: relay**
|[Full Site](https://our.intern.facebook.com/intern/staticdocs/eph/D37315947/V2/relay/)|
|**Modified Pages**|
|[docs/guides/relay-resolvers](https://our.intern.facebook.com/intern/staticdocs/eph/D37315947/V2/relay/docs/guides/relay-resolvers/)|
Reviewed By: rbalicki2
Differential Revision: D37315947
Pulled By: voideanvalue
fbshipit-source-id: 03fe54ac5bb2d6548d35e6379651a0e825beb6e2
* Reformat fbsource
Reviewed By: zertosh
Differential Revision: D37328704
fbshipit-source-id: a392a597974024bf6f0d23f9e4431d906af80b0f
* Fix docs for logs (#3988)
Summary:
At some point I forgot to note the difference between `lspOutputLevel` and `compilerOutputLevel`. This updates the README to accurately reflect what's happening in the extension.
Pull Request resolved: https://github.com/facebook/relay/pull/3988
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
**Static Docs Preview: relay**
|[Full Site](https://our.intern.facebook.com/intern/staticdocs/eph/D37346797/V2/relay/)|
|**Modified Pages**|
Reviewed By: rbalicki2
Differential Revision: D37346797
Pulled By: alunyov
fbshipit-source-id: f084fe9f39248ef070e767adf27d8baca7485c91
* Find references of the Resolver field.
Reviewed By: captbaritone
Differential Revision: D37369051
fbshipit-source-id: e1f54fd3d7576693ccf47e407002e26da077cb6b
* Bump hyper from 0.14.9 to 0.14.12 in /compiler (#3978)
Summary:
Bumps [hyper](https://github.com/hyperium/hyper) from 0.14.9 to 0.14.12.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/hyperium/hyper/releases">hyper's releases</a>.</em></p>
<blockquote>
<h2>v0.14.12</h2>
<h2>Bug Fixes</h2>
<ul>
<li><strong>ffi:</strong> on_informational callback had no headers (<a href="https://github.com/hyperium/hyper/commit/39b6d01aa0e520077bb25e16811f5ece00a224d6">39b6d01a</a>)</li>
<li><strong>http1:</strong> apply header title case for consecutive dashes (<a href="https://github-redirect.dependabot.com/hyperium/hyper/issues/2613">https://github.com/facebook/relay/issues/2613</a>) (<a href="https://github.com/hyperium/hyper/commit/684f2fa76d44fa2b1b063ad0443a1b0d16dfad0e">684f2fa7</a>)</li>
<li><strong>http2:</strong> improve errors emitted by HTTP2 <code>Upgraded</code> stream shutdown (<a href="https://github-redirect.dependabot.com/hyperium/hyper/issues/2622">https://github.com/facebook/relay/issues/2622</a>) (<a href="https://github.com/hyperium/hyper/commit/be08648e8298cdb13e9879ee761a73f827268962">be08648e</a>)</li>
</ul>
<h2>Features</h2>
<ul>
<li><strong>client:</strong> expose http09 and http1 options on <code>client::conn::Builder</code> (<a href="https://github-redirect.dependabot.com/hyperium/hyper/issues/2611">https://github.com/facebook/relay/issues/2611</a>) (<a href="https://github.com/hyperium/hyper/commit/73bff4e98c372ce04b006370c0b0d2af29ea8718">73bff4e9</a>, closes <a href="https://github-redirect.dependabot.com/hyperium/hyper/issues/2461">https://github.com/facebook/relay/issues/2461</a>)</li>
</ul>
<h2>v0.14.11</h2>
<h2>Bug Fixes</h2>
<ul>
<li><strong>client:</strong> retry when pool checkout returns closed HTTP2 connection (<a href="https://github-redirect.dependabot.com/hyperium/hyper/issues/2585">https://github.com/facebook/relay/issues/2585</a>) (<a href="https://github.com/hyperium/hyper/commit/52214f391c0a18dc66d1ccff9c0c004c5da85002">52214f39</a>)</li>
<li><strong>http2:</strong>
<ul>
<li>improve I/O errors emitted by H2Upgraded (<a href="https://github-redirect.dependabot.com/hyperium/hyper/issues/2598">https://github.com/facebook/relay/issues/2598</a>) (<a href="https://github.com/hyperium/hyper/commit/f51c677dec9debf60cb336dc938bae103adf17a0">f51c677d</a>)</li>
<li>preserve <code>proxy-authenticate</code> and <code>proxy-authorization</code> headers (<a href="https://github-redirect.dependabot.com/hyperium/hyper/issues/2597">https://github.com/facebook/relay/issues/2597</a>) (<a href="https://github.com/hyperium/hyper/commit/5243570137ae49628cb387fff5611eea0add33bf">52435701</a>)</li>
</ul>
</li>
</ul>
<h2>Features</h2>
<ul>
<li><strong>ffi:</strong> add hyper_request_on_informational (<a href="https://github.com/hyperium/hyper/commit/25d18c0b74ccf9e51f986daa3b2b98c0109f827a">25d18c0b</a>)</li>
</ul>
<h2>v0.14.10</h2>
<h2>Bug Fixes</h2>
<ul>
<li><strong>http1:</strong>
<ul>
<li>reject content-lengths that have a plus sign prefix (<a href="https://github.com/hyperium/hyper/commit/06335158ca48724db9bf074398067d2db08613e7">06335158</a>) (<strong>Security</strong> GHSA-f3pg-qwvg-p99c)</li>
<li>protect against overflow in chunked decoder (<a href="https://github.com/hyperium/hyper/commit/efd9a9821fd2f1ae04b545094de76a435b62e70f">efd9a982</a>) (<strong>Security</strong> GHSA-5h46-h7hh-c6x9)</li>
</ul>
</li>
</ul>
<h2>Features</h2>
<ul>
<li><strong>ffi:</strong> add option to get raw headers from response (<a href="https://github.com/hyperium/hyper/commit/8c89a8c1665b6fbec3f13b8c0e84c79464179c89">8c89a8c1</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/hyperium/hyper/blob/master/CHANGELOG.md">hyper's changelog</a>.</em></p>
<blockquote>
<h3>v0.14.12 (2021-08-24)</h3>
<h4>Bug Fixes</h4>
<ul>
<li><strong>ffi:</strong> on_informational callback had no headers (<a href="https://github.com/hyperium/hyper/commit/39b6d01aa0e520077bb25e16811f5ece00a224d6">39b6d01…
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The compiler playground does not currently build due to the version of parkling_lot that we are using being incompatible with wasm-pack. I manually updated the parking_lot version to
0.12in order to get it building again. This uncovered some tests which are currently failing. Updating these tests will make it easier to get the the compiler playground building again once we upgrade parking_lot officially.Currently upgrading is somewhat complicated because we try to only have one version of each dependency installed at any given time in the Meta monorepo.