It's 2024. You should use tsup instead of this.
🔥 Blazing fast builds
😇 CommonJS bundle
🌲 .mjs
bundle
✨ .d.ts
bundle + type-checking
<script lang="ts"> | |
import { defineComponent, onMounted, PropType, ref, watch } from "vue"; | |
type VoidFunction = () => void; | |
const isBrowser = () => { | |
return typeof window === "object"; | |
}; | |
export default defineComponent({ | |
props: { |
It's 2024. You should use tsup instead of this.
🔥 Blazing fast builds
😇 CommonJS bundle
🌲 .mjs
bundle
✨ .d.ts
bundle + type-checking
This document outlines how to model a common organization-based permission system in Hasura. Let's assume that you have some table structure like the following:
Table Name | Columns | Foreign Keys |
---|---|---|
User | id, name, email | |
Organization User | id, user_id, organization_id | user_id -> user.id, organization_id -> organization.id |
Organization | id, name |
brew cask install homebrew/cask-versions/adoptopenjdk8
brew cask install android-sdk
This vanilla ES6 function async
allows code to yield
(i.e. await
) the asynchronous result of any Promise
within. The usage is almost identical to ES7's async/await
keywords.
async/await
control flow is promising because it allows the programmer to reason linearly about complex asynchronous code. It also has the benefit of unifying traditionally disparate synchronous and asynchronous error handling code into one try/catch block.
This is expository code for the purpose of learning ES6. It is not 100% robust. If you want to use this style of code in the real world you might want to explore a well-tested library like co, task.js or use async/await
with Babel. Also take a look at the official async/await
draft section on desugaring.
/* | |
##Device = Desktops | |
##Screen = 1281px to higher resolution desktops | |
*/ | |
@media (min-width: 1281px) { | |
/* CSS */ | |
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft
, elem.offsetTop
, elem.offsetWidth
, elem.offsetHeight
, elem.offsetParent
'use strict'; | |
module.exports = function CustomError(message, extra) { | |
Error.captureStackTrace(this, this.constructor); | |
this.name = this.constructor.name; | |
this.message = message; | |
this.extra = extra; | |
}; | |
require('util').inherits(module.exports, Error); |
There are four kinds of deferral mechanisms in Node.js:
setTimeout
setInterval
setImmediate
process.nextTick
setTimeout
and setInterval
are quite familiar to those used to JavaScript in the browser and their semantics are fairly well understood. They return opaque values that can be passed to their clear
counterparts, and have been around forever. setImmediate
is a newer construct and its adoption in the browser is not very wide, and nextTick
is a creation solely unto Node.js. The latter two are mechanisms to queue a callback in the short future, such that currently executing JavaScript may continue. If you're used to trying to do this pattern in the browser you may be used to using something like setTimeout(fn, 0)
.
If Node.js actually exposed the idea of a turn of the event loop, you would be expecting the scheduled callback to run at the end of the current loop, or the start of the next -- though from the perspective of your application there isn't really a difference. In