- 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) { |
Mute these words in your settings here: https://twitter.com/settings/muted_keywords | |
ActivityTweet | |
generic_activity_highlights | |
generic_activity_momentsbreaking | |
RankedOrganicTweet | |
suggest_activity | |
suggest_activity_feed | |
suggest_activity_highlights | |
suggest_activity_tweet |
You are looking at the most important, and most abundant thing on the web. You can't see it, unfortunately, because it's very small… aaaaand it's invisible — so having a magnifying glass doesn't really help here. But still.
I'm talking, of course, about U+0020
; not to be confused with the band U2, who are just as ubiquitous, but far less useful.
This unicode point, representing the humble space character, is between every word, in every run of text, on every page of the web. And it has a very special characteristic: it's not sticky like glue. If two words are neighbors but there's not enough room for both of them, the space will free the second word to wrap around and start a new line.
Before getting into flexible containers, viewport meta tags, and @media
breakpoints this humble character is what makes the web fundamentally 'responsive'. That is: able to change the layout of its content to suit different devices, contexts, and settings. Browser text does this automa
1. Highlight a recommended option, | |
2. Allow users to switch currency (€/$/£) | |
3. Allow users to switch pricing monthly/yearly | |
4. Keep the entire pricing plan area clickable | |
5. Use slider to calculate how much a user would save | |
6. Provide free first month for good engagement | |
7. Prominently highlight testimonials prominently | |
8. Repeating call to action on top and bottom | |
9. Sell benefits instead of features | |
10. Indicate that users can cancel any time |
{ | |
"properties-order": [ | |
{ | |
"emptyLineBefore": true, | |
"properties": [ | |
"font", | |
"font-family", | |
"font-size", | |
"font-weight", | |
"font-style", |
Once in a while, you may need to cleanup resources (containers, volumes, images, networks) ...
// see: https://github.com/chadoe/docker-cleanup-volumes
$ docker volume rm $(docker volume ls -qf dangling=true)
$ docker volume ls -qf dangling=true | xargs -r docker volume rm
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
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.