by Ossi Hanhinen, @ohanhi
with the support of Futurice 💚.
Licensed under CC BY 4.0.
import { Component } from "React"; | |
export var Enhance = ComposedComponent => class extends Component { | |
constructor() { | |
this.state = { data: null }; | |
} | |
componentDidMount() { | |
this.setState({ data: 'Hello' }); | |
} | |
render() { |
var myString = 'EXAMPLEstring'; | |
var myNewString = myString.replace(/[A-Z]/g, '0'); | |
console.log(myNewString); | |
function replaceFunc (a, b, c) { | |
console.log(a, b, c); | |
return a.toLowerCase(); | |
} | |
var myOtherString = myString.replace(/[A-Z]/g, replaceFunc); |
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
function mapValues(obj, fn) { | |
return Object.keys(obj).reduce((result, key) => { | |
result[key] = fn(obj[key], key); | |
return result; | |
}, {}); | |
} | |
function pick(obj, fn) { | |
return Object.keys(obj).reduce((result, key) => { | |
if (fn(obj[key])) { |
Picking the right architecture = Picking the right battles + Managing trade-offs
export const GoogleApi = function(opts) { | |
opts = opts || {} | |
const apiKey = opts.apiKey; | |
const libraries = opts.libraries || []; | |
const client = opts.client; | |
const URL = 'https://maps.googleapis.com/maps/api/js'; | |
const googleVersion = '3.22'; | |
let script = null; |
The code and instructions in this gist are from http://peterdowns.com/posts/open-iterm-finder-service.html. I've had to do this a few times and wanted to distill it the basics.
Automator
Application
Actions > Utilities > Run Applescript
open_in_iterm.app
into the window.Important: At the time of writing (2019-11-11) Immutable.js is effectively abandonware, so I can no longer recommend anyone to follow the advice given here. I'll leave the article here for posterity, since it's still getting some traffic.
Functional programming principles and with it immutable data are changing the way we write frontend applications. If the recent de-facto frontend stack of React and Redux feels like it goes perfectly together with immutable data, that's because it's specifically designed for that.
There's several interesting implementations of immutable data for JavaScript, but here I'll be focusing on Facebook's own Immutable.js, and specifically on one of i
import { Component } from "React"; | |
export default (ComposedComponent) => class extends Component { | |
constructor(props) { | |
super(props); | |
this.state = { data: null }; | |
} | |
componentDidMount() { | |
this.setState({ data: 'Hello' }); | |
} |