Jihchi Lee jihchi

Async/Await - The challenges besides syntax - Cancellation

This is the second article in a series of articles around Rusts new async/await feature. The first article about interfaces can be found here.

In this part of the series we want to a look at a mechanism which behaves very different in Rust than in all other languages which feature async/await support. This mechanism is Cancellation.

Async/Await - The challenges besides syntax

4 years after after the release of Rust 1.0, it seems like Rust is now finally getting close to getting support for async/await - a language feature which aims to make it easier to write programs in an asynchronous fashion (where multiple logical tasks get multiplexed on a lower number of OS threads).

One of the last steps before the feature is stabilized is choosing the best possible syntax. The discussions around syntax have triggered an enormous

@developit/replaceall

~80b ponyfill for String.prototype.replaceAll() with good performance.

Why ponyfill? Because this is a proposal for a spec, and polyfilling it in-place before it gets solidified could break code that relies on an incorrect implementation.

Details

Alternate Version

Getting Started With Plug'n'Play

If you use create-react-app, #5136 (released with the 2.0) implements a --use-pnp option that allows you to easily create a new project using PnP! In this case, just use create-react-app --use-pnp together with Yarn 1.12, and you're good to go! 👍

Plug'n'Play is a new initiative from Yarn that aims to remove the need for node_modules. It's already available, and has proved being effective even on large-scale infrastructures. This document describes in a few steps how to quickly get started with it. Spoiler alert: it's quite easy 🙂

First, download a package manager that supports it. Yarn 1.12 already does, so that's what we're going to use! To install it, just follow the instructions on our website: https://yarnpkg.com/en/docs/install

If everything is ok, running yarn --version should give you v1.12.1 or higher. If you don't get this result maybe a

Common Bugs when Learning React

The following list tries to summarize some of the things that a developer may encounter while learning React. The list focuses on scenarios that result in actual bugs (things that don't work) or things that cause warnings in the console.

using class prop instead of className (for/htmlFor, etc...)
trying to set the style prop with a string
not having a parent element or fragment
not binding (at all or incorrectly)
using the wrong lifecycle hook
misspelling componentWillReceiveProps

The Rules of React

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.

What Functions Are "Pure"?

A number of methods in React are assumed to be "pure".

On classes that's the constructor, getDerivedStateFromProps, shouldComponentUpdate and render.

	/**
	`useChangeLog` - dev-mode helper hook to let you
	know why a memoized component re-rendered!


	Usage example:

	const YourComponent = React.memo((props) => {
	// Just drop this fella into your memo component's body.
	useChangeLog(props);

	[%bs.raw {\|require("bootstrap/dist/css/bootstrap.min.css")\|}];

	type complex = {
	value: string,
	className: string
	};

	module BtnColorContext =
	Context.MakePair({
	type t = complex;


	module StringContext =
	Context.MakePair({
	type t = string;
	let defaultValue = "Awesome";
	});

	let component = ReasonReact.statelessComponent("Tree");

	let make = _children => {

	// handy method to create a Higher Order Component out of a
	// Render Prop Component (like a Context.Consumer).
	// handles, statics, displayName, refs, and value forwarding

	function createHOCFromRenderProp({prop, Consumer}) {
	return Component => {
	function Wrapper(props, ref) {
	return (
	<Consumer>
	{value => <Component {...{...props, [prop]: value, ref}} />}