tannerlinsley

import { Merge } from 'type-fest'

type MergeGenerics<TDefaultGenerics, TUserGenerics> = Merge<
  Required<TDefaultGenerics>,
  TUserGenerics
>


interface Person {
  name: string

tannerlinsley

export default function createCrudHooks({
  baseKey,
  indexFn,
  singleFn,
  createFn,
  updateFn,
  deleteFn,
}) {
  const useIndex = (config) => useQuery([baseKey], indexFn, config)
  const useSingle = (id, config) =>

tannerlinsley

So this is kind of a multi stage plugin system. Let me explain:

Plugins get sent to the makeUseTable constructor, which then type the available options usable on useTable.

const useTable = makeUseTable({
  plugins: [myPlugin],
})

function App() {

tannerlinsley

Replacing Create React App with the Next.js CLI

How dare you make a jab at Create React App!?

Firstly, Create React App is good. But it's a very rigid CLI, primarily designed for projects that require very little to no configuration. This makes it great for beginners and simple projects but unfortunately, this means that it's pretty non-extensible. Despite the involvement from big names and a ton of great devs, it has left me wanting a much better developer experience with a lot more polish when it comes to hot reloading, babel configuration, webpack configuration, etc. It's definitely simple and good, but not amazing.

Now, compare that experience to Next.js which for starters has a much larger team behind it provided by a world-class company (Vercel) who are all financially dedicated to making it the best DX you could imagine to build any React application. Next.js is the 💣-diggity. It has amazing docs, great support, can grow with your requirements into SSR or static site generation, etc.

So why

tannerlinsley

const cache = {}

export default function useGlobalMemo (key, fn, deps) {

  if (!cache[key]) {
    cache[key] = {
      subs: 0,
      deps,
      value: fn(),
    }

tannerlinsley

// Scenario 1

const { data } = useQuery(
  'jointKey1and2',
  () => Promise.all([fetch1(), fetch2()]),
  {
    refetchInterval: 1000,
  }
)

tannerlinsley

import React from 'react'
import immer from 'immer'
//

export default function makeStore() {
  // Create a context for this store
  const context = React.createContext()

  let store = {}

tannerlinsley

Some thoughts I've gathered over the years on what I think about GraphQL. All of this is subject to change of course, and some of it may be "hot-take"-ish, but at the end of the day, I've made decisions regarding GraphQL with my customers, users, and fellow developers in mind and with the mantra that if it ultimately doesn't make a big difference for any of those people and justify the work that it requires, it's not the best investment of time. It's more important to please your users, ship products in a timely manner, and use tools that keep processes simple and familiar.

• A majority of the world still runs on REST and probably will for a while.
• The challenges of larger companies that originally benefitted from GQL are not everyones challenges and they likely never will be.
• I don't want to require my API users to have knowledge of GQL.
• Strongly typed APIs are good, but I don't particularly enjoy the tools in the ecosystem right now to use them via GQL
• GraphQL seems to have been born out of the req

tannerlinsley

function useSetUserData() {
  const [mutateUserData] = useMutation(setAirtableFields, {
    onMutate: () => {
      queryCache.setQueryData(Auth0, undefined)
    },
    // After success or failure, refetch the user query
    onSettled: () => queryCache.refetchQueries(Auth0),
  })
  
  return [mutateUserData]

tannerlinsley

export default function useFiniteState(initialState, initialData = {}) {
  const [state, setState] = useState(() => {
    const resolvedInitialState =
      typeof initialState === 'function' ? initialState : initialState()

    if (!resolvedInitialState) {
      throw new Error('An initial state is required!')
    }

    return resolvedInitialState