mjackson

Redirects in React Router v6

An important part of "routing" is handling redirects. Redirects usually happen when you want to preserve an old link and send all the traffic bound for that destination to some new URL so you don't end up with broken links.

The way we recommend handling redirects has changed in React Router v6. This document explains why.

Background

In React Router v4/5 (they have the same API, you can read about why we had to bump the major version here) we had a <Redirect> component that you could use to tell the router when to automatically redirect to another URL. You might have used it like this:

sergiodxa

import { renderToStream } from "@react-pdf/renderer";
import ReactDOMServer from "react-dom/server";
import { EntryContext, Headers, RemixServer, Request, Response } from "remix";
import PDF, { loader } from "./pdfs/my-pdf.server";

async function handlePDFRequest(request: Request, headers: Headers) {
  // get the data for the PDF
  let response = await loader({ request, context: {}, params: {} });
  // if it's a response return it, this means we redirected
  if (response instanceof Response) return response;

ryanflorence

meta
title Mutations with Actions and Form | Remix

import { Link } from "react-router-dom";

Mutations with Actions and <Form>

Data mutations in Remix are built on top of two fundamental web APIs: `` and HTTP. We then use progressive enhancement to enable optimistic UI, loading indicators, and validation feedback--but the programming model is still built on HTML forms.

ryanflorence

Reach UI Philosophy

Reach UI is an accessible foundation for React applications and design systems.

The three equally important goals are to be:

• Accessible
• Composable
• Stylable

addyosmani

Some quick thoughts on https://twitter.com/dan_abramov/status/884892244817346560. It's not ignorant at all to ask how browser vendors approach performance. On the V8 side we've discussed bytecode precompilation challenges a few times this year. Here's my recollection of where we stand on the idea:

JavaScript engines like V8 have to work on multiple architectures. Every version of V8 is different. The architectures we target are different. A precompiled bytecode solution would require a system (e.g the server or a CDN) to generate bytecode builds for every target architecture, every version of V8 supported and every version of the JavaScript libraries or bundles bytecode is being generated for. This is because we would need to make sure every user accessing a page using that bytecode can still get the final JS successfully executed.

Consider that if a cross-browser solution to this problem was desired, the above would need to be applied to JavaScriptCore, SpiderMonkey and Chakra as well. It would need to ca

arunoda

module.exports = {
  webpack: function (cfg) {
    cfg.plugins = cfg.plugins.filter(plugin => {
      return plugin.constructor.name !== 'UglifyJsPlugin';
    });

    return plugin
  }
}

ryanflorence

import React, { Component } from 'react'
import logo from './logo.svg'
import './App.css'

import { Route, Link, Redirect } from './Zero'

const paths = [ 'one', 'two', 'three' ]

class App extends Component {
  render() {

sergiodxa

// with props
import React, { Component } from 'react';

// this method work as a our base `handleClick` function
function handleClick(name, event) {
  alert(`hello ${name}`);
}

class App extends Component {
  constructor(props) {