Although @setup/node as a built-in cache option, it lacks an opportunity regarding cache persistence. Depending on usage, the action below might give you faster installs and potentially reduce carbon emissions (♻️🌳❤️).
Yarn 3+/4+ with nodeLinker: node-modules. (Not using yarn ? see the corresponding pnpm 7/8+ action gist)
| /* | |
| Made by Elly Loel - https://ellyloel.com/ | |
| With inspiration from: | |
| - Josh W Comeau - https://courses.joshwcomeau.com/css-for-js/treasure-trove/010-global-styles/ | |
| - Andy Bell - https://piccalil.li/blog/a-modern-css-reset/ | |
| - Adam Argyle - https://unpkg.com/open-props@1.3.16/normalize.min.css / https://codepen.io/argyleink/pen/KKvRORE | |
| Notes: | |
| - `:where()` is used to lower specificity for easy overriding. | |
| */ |
| function! s:format_qf_line(line) | |
| let parts = split(a:line, ':') | |
| return { 'filename': parts[0] | |
| \,'lnum': parts[1] | |
| \,'col': parts[2] | |
| \,'text': join(parts[3:], ':') | |
| \ } | |
| endfunction | |
| function! s:qf_to_fzf(key, line) abort |
https://twitter.com/snookca/status/1073299331262889984?s=21
Happy to chat about this. There’s an obvious disclaimer that there’s a cost to css-in-js solutions, but that cost is paid specifically for the benefits it brings; as such it’s useful for some usecases, and not meant as a replacement for all workflows.
(These conversations always get heated on twitter, so please believe that I’m here to converse, not to convince. In return, I promise to listen to you too and change my opinions; I’ve had mad respect for you for years and would consider your feedback a gift. Also, some of the stuff I’m writing might seem obvious to you; I’m not trying to tell you if all people of some of the details, but it might be useful to someone else who bumps into this who doesn’t have context)
So the big deal about css-in-js (cij) is selectors.
| /** | |
| * @param {number} yPos Pixels from the top of the screen to scroll to | |
| * @param {number} duration Time of animation in milliseconds | |
| */ | |
| const scrollTo = (yPos, duration = 600) => { | |
| const startY = window.scrollY; | |
| const difference = yPos - startY; | |
| const startTime = performance.now(); | |
| const step = () => { |
| #!/bin/bash | |
| # For instance with feature/add_new_feature_HEYT-653 | |
| # $ git commit -m"Fixed bug" | |
| # will result with commit "[HEYT-653] Fixed bug" | |
| # Customize which branches should be skipped when prepending commit message. | |
| if [ -z "$BRANCHES_TO_SKIP" ]; then | |
| BRANCHES_TO_SKIP=(master develop test) |
| function throttle(callback, wait, immediate = false) { | |
| let timeout = null | |
| let initialCall = true | |
| return function() { | |
| const callNow = immediate && initialCall | |
| const next = () => { | |
| callback.apply(this, arguments) | |
| timeout = null | |
| } |
| // note: I'm using redux-actions in here, so the actions might look a bit different than you are used too | |
| // note: This is not complete but the concepts are | |
| // excerpt from app.js | |
| import { createStore, applyMiddleware } from 'redux'; | |
| import thunk from 'redux-thunk'; | |
| import fetch from 'isomorphic-fetch' | |
| // note: you could totally leave out the fetch argument here if you set a default (as I do in my actions) | |
| // I'm right now not absolutely sure how I will handle this in the future (the way it is now it is a bit redundant) |
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