All libraries have subtle rules that you have to follow for them to work well. Often these are implied and undocumented rules that you have to learn as you go. This is an attempt to document the rules of React renders. Ideally a type system could enforce it.
A number of methods in React are assumed to be "pure".
On classes that's the constructor, getDerivedStateFromProps, shouldComponentUpdate and render.
I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.
I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.
Chrome 51 has some pretty wild behaviour related to console.log in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.
| // ==UserScript== | |
| // @name @chaoticvibing Twitter Blue Nerd - twitter.com | |
| // @namespace Violentmonkey Scripts | |
| // @match *://*.twitter.com/* | |
| // @grant none | |
| // @version 1.9.1 | |
| // @author @chaoticvibing - GH @busybox11 | |
| // @description 11/9/2022, 11:45:28 PM | |
| // @updateURL https://gist.githubusercontent.com/busybox11/53c76f57a577a47a19fab649a76f18e3/raw/twitterblue-nerd.js | |
| // @downloadURL https://gist.githubusercontent.com/busybox11/53c76f57a577a47a19fab649a76f18e3/raw/twitterblue-nerd.js |
| (function (context, trackingId, options) { | |
| const history = context.history; | |
| const doc = document; | |
| const nav = navigator || {}; | |
| const storage = localStorage; | |
| const encode = encodeURIComponent; | |
| const pushState = history.pushState; | |
| const typeException = 'exception'; | |
| const generateId = () => Math.random().toString(36); | |
| const getId = () => { |
Hmm... I don't see any docs for 4.0 on https://webpack.js.org. I guess I'll just wing it.
All I need to do is npm i -D webpack@next, right?
+ webpack@4.0.0-beta.2
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.
The first post has been published: https://www.swyx.io/writing/cloud-distros
The second post has been adapted for Temporal: https://www.swyx.io/why-temporal/
these are bullet points of a blogpost on a topic i know very little about but i feel like there is something there that is happening as we speak
| import React, { Children } from 'react' | |
| import Router from 'next/router' | |
| import smoothScroll from '../utils/smoothScroll' | |
| // this HOC is taken from https://github.com/zeit/next.js/blob/master/lib/link.js and modified | |
| export default class LinkSmoothScroll extends React.Component { | |
| constructor (props) { | |
| super(props) | |
| this.linkClicked = this.linkClicked.bind(this) | |
| } |
| let UserContext = React.createContext(); | |
| class App extends React.Component { | |
| state = { | |
| user: null, | |
| setUser: user => { | |
| this.setState({ user }); | |
| } | |
| }; |