captbaritone

thread 'typescript_resolver_with_context' panicked at /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/spin-0.9.8/src/once.rs:230:42:
Once panicked
stack backtrace:
   0:        0x1035d6dfc - std::backtrace_rs::backtrace::libunwind::trace::h766402c5a352d06e
                               at /rustc/6b9676b45431a1e531b9c5f7bd289fc36a312749/library/std/src/../../backtrace/src/backtrace/libunwind.rs:116:5
   1:        0x1035d6dfc - std::backtrace_rs::backtrace::trace_unsynchronized::hc3869f900690ffb5
                               at /rustc/6b9676b45431a1e531b9c5f7bd289fc36a312749/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:        0x1035d6dfc - std::sys::backtrace::_print_fmt::hf5652c8929173e8f
                               at /rustc/6b9676b45431a1e531b9c5f7bd289fc36a312749/library/std/src/sys/backtrace.rs:66:9
   3:        0x1035d6dfc - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h60a58853ec454374

captbaritone

Defining Directives

You can define GraphQL directives by placing a @gqlDirective before a:

• Function declaration
• Arrow function declaration

/**
 * @gqlDirective 

captbaritone

You can annotate parts of your Grats GraphQL schema with directives (link to define directives) using the @gqlAnnotate docblock tag.

/**
 * @gqlQueryField
 * @gqlAnnotate myDirective
 */
export function greet(): string {
  return "Hello";
}

captbaritone

One day at work I noticed a stray } at the bottom of a page of our product. I went searching for it, and found the culprit: during a refactor a } which had previously been used to enclose an expression within some JSX had been left behind. It occurred to me that this was likely a common error and something that could be linted for. I slapped together a quick rule that reported certain syntax characters that tend to get left behind (like ), ;, >, } or })) as a lint error.

I ran the rule on the code base and to my surprise there were a few hundred examples of stray characters in our UI. A few weeks later a similar bug cropped up in a separate codebase at work where I had not enabled the rule. My colleague Brad Zacher remembered my lint rule and suggested it get added there as well. However, at that point an engineer on the Flow team suggested maybe Flow could just make some of these characters a syntax error. They did and uncovered and fixed a few

captbaritone

JavaScript Resolver Directive Spec

This document (DRAFT) describes GraphQL directives used to annotate a GraphQL schema which is backed by JavaScript resolvers. Its goal is to encode enough information that a complete GraphQL executor for the schema can be inferred directly from the GraphQL Schema Definition Language (SDL) document. This approach is especially attractive for implementation-first servers where the GraphQL schema and how to execute it can be inferred directly from the resolver code itself.

Motivation

Ideally this scheme can enabling decoupling and interoperability between tools. For example:

• Tools that could generate SDL with these directives:
• Grats

captbaritone

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "ConfigFile",
  "anyOf": [
    {
      "description": "Base case configuration (mostly of OSS) where the project have single schema, and single source directory",
      "type": "object",
      "required": [
        "language"
      ],

captbaritone

0. Relay Live Resolvers

Relay Liver Resolvers are an experimental Relay feature which lets you extend your server’s GraphQL schema to include additional client state. For example, you might want to expose data from a legacy state management solution or from IndexDB to your Relay components.

Your experience writing GraphQL resolvers on the server should mostly apply to writing Live Resolvers. The main distinction is that Live Resolvers are reactive. Instead of just reading a single values, Live Resolvers model a value that might change over time, similar to an observable.

Pages

• 01. Relay Resolver Syntax

captbaritone

This rule lints for non-colocated fragment spreads within queries or fragments. In other words, situations where a fragment is spread in module A, but the module (B) that defines that fragment is not imported by module A. It does not lint subscriptions or mutations. This catches:

• The anti-pattern of spreading a fragment in a parent module, then passing that data down to a child module, or jamming it all in context. This defeats the purpose of Relay. From the Relay docs – "[Relay] allows components to specify what data they need and the Relay framework provides the data. This makes the data needs of inner components opaque and allows composition of those needs."
• Instances where fragment spreads are unused, which results in overfetching. In addition to consuming more gCPU, it can also sometimes cause SEVs: D19057571

When the fragment is unused

The easiest way to tell if a fragment is unused is to remove the line containing the lint error, run js1 rebuild relay, the

captbaritone

'use strict';

const {ROOT_DIR} = require('../../utils/config/index.js');
var fs = require('fs');
const OSS_DIR = `${ROOT_DIR}/xplat/js/RKJSModules/Libraries/Relay/oss`;
const COMPILER_TARGETS_FILE = `${ROOT_DIR}/fbcode/relay/oss/crates/relay-compiler/TARGETS`;
const COMPILER_CARGO_FILES = [
  `${ROOT_DIR}/fbcode/relay/oss/crates/relay-compiler/Cargo.toml`,
  `${ROOT_DIR}/fbcode/relay/oss/Cargo.oss.lock`,
];

captbaritone

const EQUALITY_OPERATORS = new Set(['==', '===', '!=', '!==']);

module.exports = {
  meta: {
    messages: {
      constant: 'Constant condition.',
      coalescingNeverNullish: 'Constant condition. Value can never be nullish.',
      coalescingAlwaysNullish:
        'Constant condition. Value will always be nullish.',
    },