- Location - The location of the application. Usually just a URL, but the location can contain multiple pieces of information that can be used by an app
- pathname - The "file/directory" portion of the URL, like
invoices/123
- search - The stuff after
?
in a URL like/assignments?showGrades=1
. - query - A parsed version of search, usually an object but not a standard browser feature.
- hash - The
#
portion of the URL. This is not available to servers inrequest.url
so its client only. By default it means which part of the page the user should be scrolled to, but developers use it for various things. - state - Object associated with a location. Think of it like a hidden URL query. It's state you want to keep with a specific location, but you don't want it to be visible in the URL.
- pathname - The "file/directory" portion of the URL, like
import { Machine, assign } from 'xstate'; | |
import firebase from './firebase'; | |
const chart = { | |
id: 'auth', | |
context: { | |
auth: null, | |
error: null, | |
loggedoutTime: null | |
}, |
import { useState, useEffect, useRef, useCallback } from 'react'; | |
import useThrottledOnScroll from './useThrottledOnScroll'; | |
const useScrollSpy = ({ items = [], target = window } = {}) => { | |
const itemsWithNodeRef = useRef([]); | |
useEffect(() => { | |
itemsWithNodeRef.current = getItemsClient(items); | |
}, [items]); | |
const [activeState, setActiveState] = useState(null); |
This is a work in progress. Please don't take this as something that will definitely happen, we all know what happens to well laid plans and I need to present it to the rest of the TypeScript team in order to figure out a lot of feasibility questions.
The examples in this PR assumes [CLI DX] Improve positioning of compiler error messaging info #45717 is merged
In 4.4, all diagnostic messages from TypeScript are treated the same, we have a massive .JSON file of ±2000 diagnostic messages which are used everywhere from compiler messages to CLI help. Aside from some simple string manipulation, these are effectively what we output for all error messages. I'd like to propose that we break this pattern, just for error TS2322.
TS2322 is our 'type x is not assignable to y' error, you'd see it for const str: string = 123
and I expect it is the most seen
// app/routes/api/auth/$.ts | |
import NextAuth from "~/lib/next-auth/index.server"; | |
export const { action, loader } = NextAuth({ | |
providers: [ | |
GoogleProvider({ | |
clientId: env.GOOGLE_CLIENT_ID, | |
clientSecret: env.GOOGLE_CLIENT_SECRET, | |
}), | |
], |