Skip to content

Instantly share code, notes, and snippets.


Eloy Durán alloy

View GitHub Profile
View relay-runtime-deferred-data-in-initial-response.diff
diff --git a/node_modules/relay-runtime/lib/store/RelayResponseNormalizer.js b/node_modules/relay-runtime/lib/store/RelayResponseNormalizer.js
index b9994b3..e970570 100644
--- a/node_modules/relay-runtime/lib/store/RelayResponseNormalizer.js
+++ b/node_modules/relay-runtime/lib/store/RelayResponseNormalizer.js
@@ -351,6 +351,7 @@ var RelayResponseNormalizer = /*#__PURE__*/function () {
if (process.env.NODE_ENV !== "production") {
process.env.NODE_ENV !== "production" ? warning(typeof isDeferred === 'boolean', 'RelayResponseNormalizer: Expected value for @defer `if` argument to ' + 'be a boolean, got `%s`.', isDeferred) : void 0;
+ invariant(defer.selections[0].kind === "InlineFragment" && defer.selections[0].selections.length > 0, "RelayResponseNormalizer: Expected @defer on InlineFragment with selections");
alloy /
Last active July 6, 2022 14:45
Benchmark various GraphQL resolving variants

Benchmark various GraphQL resolving variants

There exists confusion about how a GraphQL execution engine like graphql-js does its work. The engine will invoke a resolve function for every [scalar] field in a request.

  • defaultFieldResolver: By default graphql-js will invoke its own defaultFieldResolver resolve function when no explicit resolver was specified when generating the executable schema. This resolver needs to do some reflection on the request in order to determine what data to return.
  • explicitDefaultFieldResolver: We can also use graphql-js's defaultFieldResolver explicitly, which will skip a check for whether or not a field resolver function was specified when generating the executable schema.
  • customFieldResolver: We can also specify our own field resolver function that does not need to perform any reflection, as we know what type to return.
  • customAsyncFieldResolver: Custom field resolvers can also be async. This doesn't make their own execution time much worse, but scheduli
View gist:7e398a8769bf00536f13acc072fc3403

In our application, we have a need to wrap Apollo Client, amongst other reasons we do this to pass default link context to operations. This works well for operations originating from the top-level APIs, but it doesn't for the subscribeToMore function that gets created by useQuery.

We could augment useQuery further and also wrap each subscribeToMore function object that's created, but it struck us that the relationship between the useQuery invocation and the created subscribeToMore function might actually imply that it should inherit the link context of the useQuery invocation. Below you can find a naive patch that does this.

// src/core/ObservableQuery.ts  

public subscribeToMore< 
      TSubscriptionData = TData, 
alloy / Pure vs Fragmentized Component Trees and Propagated vs Connected Data Propagation.svg
Last active April 12, 2022 11:28
I’ve been drawing up an overview of pure vs GraphQL fragmentized [React] UI components, different ways to propagate data through the tree, and the associated maintenance/performance considerations.
View Pure vs Fragmentized Component Trees and Propagated vs Connected Data Propagation.svg
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
alloy / LiveQueryPolyfill.ts
Last active February 24, 2021 15:09
Rewrite GraphQL Live Query to subscription.
View LiveQueryPolyfill.ts
* This is a Live Query polyfill, as graphql-js does not strictly have support for that. Instead, we leave it up to the
* client to recognize a Live Query is requested with the `@live` directive on a `query` operation and here we
* transform it into a `live` subscription instead.
* Consider a schema like the following:
* ```graphql
type Badge {
id: ID!
View 1 - schema.graphql
scalar Date
type Query {
badge: Badge!
type Badge {
key: BadgeKey!
text: String!
history: BadgeHistoryConnection!
View glob.json
alloy / build-settings.rb
Created April 28, 2020 14:43
Example of ways to introspect Xcode build settings
View build-settings.rb
# gem install xcodeproj claide hashdiff
require 'xcodeproj'
require 'claide'
require 'pp'
argv =
project_path = argv.shift_argument
target_name = argv.option("target")
target_type = argv.option("target-type", "PBXNativeTarget")
View dump-target-build-settings.rb
require 'xcodeproj'
require 'pp'
unless (project_path = ARGV[0]) && (target_name = ARGV[1])
raise "Usage: ruby #{__FILE__} path/to/the.xcodeproj target-name [diff-base-config]"
project =
target = project.targets.find { |t| == target_name }
alloy / stderr.txt
Last active February 28, 2020 21:36
v0.62.0-rc.3 CHANGELOG
View stderr.txt
~/C/R/r/releases [changelog-fixes] » yarn generate -b v0.61.5 -c v0.62.0-rc.3 -r ../../react-native -f ./ -t [GITHUB-TOKEN]
Resolve base commit
Fetch commit data