| 'use client'; | |
| import { useEffect, useRef, useState } from 'react'; | |
| export type UnicornSceneProps = { | |
| projectId: string; | |
| width?: number | string; | |
| height?: number | string; | |
| scale?: number; | |
| dpi?: number; |
I needed this for priming some image-heavy pages that were slow to cold-load after a cleared cache.
It's ideal for pages with some form of lazyloading / async content pulled from a CDN or a CMS where the first request can take an unacceptably long time to fulfill.
It also generates full page screenshots which can be used in QA or rudimentary visual regression testing.
npm i puppeteer yargs chalk-animation
| In /etc/nginx/ I have a file called errors.conf, which should try and pass errors to a error.php file in /var/www/admin/public | |
| ---- | |
| # Error handler, codes can also be combined | |
| error_page 401 /error.php?c=401; | |
| error_page 403 /error.php?c=403; | |
| error_page 404 /error.php?c=404; | |
| error_page 500 /error.php?c=500; | |
| error_page 502 503 504 /error.php?c=50x; |
| In a nut shell... it would be nice if instead of | |
| @include media ($tablet) { | |
| text-align: right; | |
| } | |
| @include media ($desktop) { | |
| text-align: right; | |
| } |
| <!DOCTYPE html> | |
| <html lang="en"> | |
| <head> | |
| <meta charset="utf-8"> | |
| <title>2-column “responsive” masonry layout without JS plugins</title> | |
| <!--[if lt IE 9]><script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]--> | |
| <style> | |
| body { | |
| text-align: center; | |
| } |
Sass 3.2 makes working with media queries a lot easier, mostly by clearing the way for mix-ins going by the name of "breakpoint" or "respond-to".
The basic pattern of defining queries and assigning them aliases that can be passed with includes that trigger full-blown rules is great, but it would also be nice if we could select/combine and otherwise extend control over these disparate rules with a little more flexibility.
Using the example respond-to below, I would love it if @include respond-to(large-screen && retina) would have the same effect as nesting these individual respond-to()'s within each other, and the rule(s) contained within would be applied when both queries matched (the screen is both large and retina).
The ability to conjoin a min and max width range of individual queries with something like respond-to(small-screen || medium-screen) woul