- 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
/* Using a JavaScript proxy for a super low code REST client */ | |
// via https://dev.to/dipsaus9/javascript-lets-create-aproxy-19hg | |
// also see https://towardsdatascience.com/why-to-use-javascript-proxy-5cdc69d943e3 | |
// also see https://github.com/fastify/manifetch | |
// also see https://github.com/flash-oss/allserver | |
// and https://gist.github.com/v1vendi/75d5e5dad7a2d1ef3fcb48234e4528cb | |
const createApi = (url) => { | |
return new Proxy({}, { | |
get(target, key) { |
import ReactDOMServer from "react-dom/server"; | |
import type { EntryContext } from "@remix-run/core"; | |
import Remix from "@remix-run/react/server"; | |
import { renderToString } from "react-dom/server"; | |
import { ServerStyleSheet } from "styled-components"; | |
import StylesContext from "./stylesContext"; | |
export default function handleRequest( | |
request: Request, |
{ | |
"name": "workshop-setup", | |
"version": "1.0.0", | |
"description": "This is the common setup script for most of my workshops", | |
"bin": "./setup.js" | |
} |
const bypass = [ | |
// function names to avoid logging | |
]; | |
const collapsed = [ | |
// function names to groupCollapsed | |
]; | |
module.exports = function(babel) { | |
const { types: t } = babel; | |
const wrapFunctionBody = babel.template(`{ |
declare namespace shaka { | |
namespace util { | |
/** | |
* A timer allows a single function to be executed at a later time or at regular intervals. | |
*/ | |
class Timer { | |
/** | |
* Create a new timer. A timer is committed to a single callback function. While there is no technical reason to do this, it is far easier to understand and use timers when they are connected to one functional idea. | |
*/ | |
constructor(onTick: (() => void)); |
The trend of using monorepos makes a lot of things easier to manage. However, when you want to fork a single package inside a monorepo, you'll have to chose one of two options:
- Fork the entire monorepo (meaning you get all those extra boilerplate you don't really care about)
- Manually copying the package files into a new git repo (meaning you'll loose all git history and have a lot of work to do when there's a new version of your base package)
The good news: There's a solution for this! And it's actually built in to git.
One of the lesser-known (and vaguely documented) features of git is subtree
. It's intended for this purpose, working as a great alternative to the criticized submodules
.
There are very few resources about using this in practice, so here's a guide for this specific use case.
require('isomorphic-fetch'); | |
fetch('https://1jzxrj179.lp.gql.zone/graphql', { | |
method: 'POST', | |
headers: { 'Content-Type': 'application/json' }, | |
body: JSON.stringify({ query: '{ posts { title } }' }), | |
}) | |
.then(res => res.json()) | |
.then(res => console.log(res.data)); |
If you have already seen Richard Feldman's talk entitled "Making Impossible States Impossible" or have read "Designing with types: Making illegal states unrepresentable" then you can skip the explanations and just head straight to the Reason examples.
This post is intended to display how to model your Reason Application to prevent creating impossible states. The benefits of being able to design a feature in this way include avoiding having to deal with complex test scenarios regarding defined business rules and a clear documentation of what is possible just by looking at the type definition. Long story short, let's see how this all works by implementing an example.
watchman watch-del-all && rm -rf node_modules/ && yarn cache clean && yarn install && yarn start -- --reset-cache |