2015.10.07 t
Quick tip for handling CSRF Token Expiration - common issue is when you use csrf protection is that if | |
a form sits there for a while (like a login form, but any the same) the csrf token in the form will | |
expire & throw a strange error. | |
Handling it is simple, and is a good lesson for dealing with other types of errors in a custom manner. | |
In Middleware you will see a file VerifyCsrfToken.php and be tempted to handle things there. DON'T! | |
Instead, look at your app/Exceptions/Handler.php, at the render($request, Exception $e) function. | |
All of your exceptions go through here, unless you have excluded them in the $dontReport array at the |
<script> | |
// A minimal polyfill for copying text to clipboard that works most of the time in most capable browsers. | |
// Note that: | |
// - You may not need this. `navigator.clipboard.writeText()` works directly in all modern browsers as of 2020. | |
// - In Edge, this may call `resolve()` even if copying failed. | |
// - In Safari, this may fail if there is nothing selected on the page. | |
// See https://github.com/lgarron/clipboard-polyfill for a more robust solution. | |
// | |
// License for this Gist: public domain / Unlicense | |
function writeText(str) { |
/* Sometimes it's pretty easy to run ito troubles with React ES6 components. | |
Consider the following code: */ | |
class EventStub extends Component { | |
componentDidMount() { | |
window.addEventListener('resize', this.onResize.bind(this)); //notice .bind | |
} | |
componentWillUnmount() { | |
window.removeEventListener('resize', this.onResize.bind(this)); |
<?php | |
$finder = Symfony\Component\Finder\Finder::create() | |
->notPath('bootstrap/cache') | |
->notPath('storage') | |
->notPath('vendor') | |
->in(__DIR__) | |
->name('*.php') | |
->notName('*.blade.php') | |
->ignoreDotFiles(true) |
/** | |
* Loads an HTML document from a URL and retuns an element selected using | |
* the 'selector' parameter | |
* Example usage: | |
* loadPageSection('./myPage.html', '#container', (r, err) => console.log(r, err)); | |
* | |
* @method loadPageSection | |
* @param {String} url | |
* @param {String} selector - A valid CSS selector | |
* @param {Function} callback - To be called with two parameters (response, error) |
<!doctype html> | |
<html lang="en"> | |
<head> | |
<meta charset="utf-8"> | |
<meta name="viewport" content="width=device-width, initial-scale=1.0"> | |
<title>Critical FOFT with preload</title> | |
<link rel="preload" href="/web/css/fonts/lato/lato-zachleat-optimized.woff2" as="font" type="font/woff2" crossorigin> | |
<style> | |
@font-face { | |
font-family: LatoSubset; |
Years ago, some smart folks that worked on JS engines realized that not all JS that's loaded into a page/app initially is needed right away. They implemented JIT to optimize this situation.
JIT means Just-In-Time, which means essentially that the engine can defer processing (parsing, compiling) certain parts of a JS program until a later time, for example when the function in question is actually needed. This deferral means the engine is freer to spend the important cycles right now on the code that's going to run right now. This is a really good thing for JS performance.
Some time later, some JS engine devs realized that they needed to get some hints from the code as to which functions would run right away, and which ones wouldn't. In technical speak, these hints are called heuristics.
So they realized that one very common pattern for knowing that a function was going to run right away is if the first character before the function
keyword was a (
, because that usually m
<template> | |
<div> | |
<button @click="increment">Increment</button> | |
</div> | |
</template> | |
<script> | |
import { mapActions } from 'vuex' | |
export default{ | |
methods: { |
You probably arrived here because of a curt message in response to an issue you filed on a repo that I contribute to. Sorry about that (particularly if you filed the issue long ago and have been waiting patiently for a response). Let me explain:
I work on a lot of different open source projects. I really do like building software that makes other people's lives easier, but it's crazy time-consuming. One of the most time-consuming parts is responding to issues. A lot of OSS maintainers will bend over backwards to try and understand your specific problem and diagnose it, to the point of setting up new test projects, fussing around with different Node versions, reading the documentation for build tools that we don't use, debugging problems in third party dependencies that appear to be involved in the problem... and so on. I've personally spent hundreds of hours of my free time doing these sorts of things to try and help people out, because I want to be a responsible maintainer and I