Skip to content
View butaud's full-sized avatar

Block or report butaud

Block user

Prevent this user from interacting with your repositories and sending you notifications. Learn more about blocking users.

You must be logged in to block users.

Maximum 250 characters. Please don't include any personal information such as legal names or email addresses. Markdown supported. This note will be visible to only you.
Report abuse

Contact GitHub support about this user’s behavior. Learn more about reporting abuse.

Report abuse

Pinned Loading

  1. shared-tasks shared-tasks Public

    TypeScript 2

  2. useQuery semantics useQuery semantics
    1
    # useQuery semantics
    2
    On my team, we've had some confusion lately about the behavior of `useQuery` and how the `fetchPolicy` parameter influences it. Looking back through the Apollo documentation, I think it just doesn't do a very good job of explaining some of these subtleties, but the behavior itself is logical once you have the right mental model of what the hook is supposed to do.
    3
    
                  
    4
    ## useQuery is a description, not an operation
    5
    Some of the confusion around useQuery's behavior comes from thinking of it as an operation, something that you call to execute a specific query. But this isn't the right way to think about it - instead, you should think of it as a way to tell Apollo that a particular instance of a component is associated with a particular query. Apollo will, of course, fetch the query data and provide the results to the component, but the timing and frequency of the actual fetch depends on the lifecycle of the component, not on the number of times useQuery is called during render passes.
  3. minutes-taker minutes-taker Public

    App to take minutes and export

    TypeScript

  4. prepare-to-board prepare-to-board Public

    TypeScript

  5. wordle-cloud wordle-cloud Public

    Display results from Wordle

    TypeScript

  6. How to think about nullability in Ty... How to think about nullability in Typescript
    1
    # How to think about nullability in Typescript
    2
    A lot of time people approach Typescript with the mindset that it's halfway between an untyped language like Javascript and a traditional statically typed language. That might be true in some ways, but when it comes to nullability, Typescript (the way it's typically used) is actually much more strict/expressive than traditional languages like C, Java, and C#, and you might be led astray if you don't take that into account.
    3
     
    4
    ## Javascript vs C# vs Typescript
    5
    In Javascript, values are completely untyped and you can of course assign any value to any variable or parameter, including `null` and `undefined`. There is no compiler, and if you want your code to be protected against invalid values you will have to write your own runtime checks.