orta

This is a work in progress. Please don't take this as something that will definitely happen, we all know what happens to well laid plans and I need to present it to the rest of the TypeScript team in order to figure out a lot of feasibility questions.

Intro

The examples in this PR assumes [CLI DX] Improve positioning of compiler error messaging info #45717 is merged

In 4.4, all diagnostic messages from TypeScript are treated the same, we have a massive .JSON file of ±2000 diagnostic messages which are used everywhere from compiler messages to CLI help. Aside from some simple string manipulation, these are effectively what we output for all error messages. I'd like to propose that we break this pattern, just for error TS2322.

TS2322 is our 'type x is not assignable to y' error, you'd see it for const str: string = 123 and I expect it is the most seen

threepointone

(I'm enjoying doing these raw, barely edited writeups; I hope they're useful to you too)

Feature flags

This is my own writeup on feature flags; for a deep dive I'd recommend something like Martin Fowler's article (https://martinfowler.com/articles/feature-toggles.html).

So. Feature flags. The basic idea that you'll store configuration/values on a database/service somewhere, and by changing those values, you can change the user experience/features for a user on the fly.

Let's say that you're building a new feature, called 'new-button' which changes the color of buttons, which is currently red, to blue. Then you'd change code that looks like this -

bergmannjg

Building a react native app in WSL2

Install, build and debug a react native app in WSL2 (Windows Subsystem for Linux) and Ubuntu.

• Install tools in Windows
• Install tools in WSL2
• Connect to android hardware device from WSL2
• Connect to android virtual device in Windows
  • Start android virtual device in Windows
• Start adb server in Windows

gaearon

const express = require('express');
const app = express();

// Application
app.get('/', function(req, res) {
  if (process.env.NODE_ENV === 'development') {
    for (var key in require.cache) {
      delete require.cache[key];
    }      
  }

sebmarkbage

I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.

I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.

"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr

ryanflorence

Everything I Know About UI Routing

Definitions

1. 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
   1. pathname - The "file/directory" portion of the URL, like invoices/123
   2. search - The stuff after ? in a URL like /assignments?showGrades=1.
   3. query - A parsed version of search, usually an object but not a standard browser feature.
   4. hash - The # portion of the URL. This is not available to servers in request.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.
   5. 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.

Rich-Harris

I've been deceiving you all. I had you believe that Svelte was a UI framework — unlike React and Vue etc, because it shifts work out of the client and into the compiler, but a framework nonetheless.

But that's not exactly accurate. In my defense, I didn't realise it myself until very recently. But with Svelte 3 around the corner, it's time to come clean about what Svelte really is.

Svelte is a language.

Specifically, Svelte is an attempt to answer a question that many people have asked, and a few have answered: what would it look like if we had a language for describing reactive user interfaces?

A few projects that have answered this question:

mgreer

// @flow
import * as React from 'react';
import {asyncComponent} from 'react-async-component';

export const loaderMaker = (bgColor: string = 'transparent') => () => (
  <div style={{position: 'absolute', width: '100%', height: '100%', backgroundColor: bgColor}} />
);

const MAX_RETRIES = 3;
const STARTING_BACKOFF = 500;

gaearon

Note:

When this guide is more complete, the plan is to move it into Prepack documentation.
For now I put it out as a gist to gather initial feedback.

A Gentle Introduction to Prepack (Part 1)

If you're building JavaScript apps, you might already be familiar with some tools that compile JavaScript code to equivalent JavaScript code:

• Babel lets you use newer JavaScript language features, and outputs equivalent code that targets older JavaScript engines.

divyanshu013

for f in *.gif; do
 convert $f'[0]' $f'.png'
done