Common scenarios for setting up TS and React scenarios

  • New project — usecreat-react-appCreate – Scaffolding builds TS using Babel
  • New project — usets-loaderCreate – scaffolding builds TS using TS-Loader
  • Old project – select loader, change.js to.ts. …). I don’t expand it here


You are advised to use TS-Loader to simplify configuration

Import module the similarities and differences of the four writing methods

const path = require(‘path’)


This is not recommended in TS because the CommonJS method exports any and has no type support


import * as path from ‘path’ / import { resolve } from ‘path’

This is a fairly common way of writing, which is to export the entire module,

One thing to note is the effect of a configuration “esModuleInterop”:true in ts.config on this compilation


There are test.ts files:


import * as path from ‘path’

console.log(path);


Test.js compiled without esModuleInterop:


“use strict”;

Object.defineProperty(exports, “__esModule”, { value: true });

const path = require(“path”);

console.log(path);


Configure esModuleInterop: True when compiling the test.js file:


“use strict”;

var __importStar = (this && this.__importStar) || function (mod) {

if (mod && mod.__esModule) return mod;

var result = {};

if (mod ! = null) for (var k in mod) if (Object.hasOwnProperty.call(mod, k)) result[k] = mod[k];

result[“default”] = mod;

return result;

};

Object.defineProperty(exports, “__esModule”, { value: true });

const path = __importStar(require(“path”));

console.log(path);


The purpose of this configuration is added to prevent if you use the import import other source files within the program, because the original commonjs wording, it will prompt you file “/ path/to/project/SRC/mod. The ts” is not a module. Ts (2306). In this case, you need to change the imported module to ES6 export

import mod from ‘mod’

This syntax is exported by default, so be careful


The test.ts file is as follows

import path from ‘path’

console.log(path)


The compiled test.js file:


“use strict”;

var __importDefault = (this && this.__importDefault) || function (mod) {

return (mod && mod.__esModule) ? mod : { “default”: mod };

};

Object.defineProperty(exports, “__esModule”, { value: true });

const path_1 = __importDefault(require(“path”));

console.log(path_1.default);


Import mod returns module.exports if the imported module’s __esModule is true. Import mod returns module.exports if __esModule is true. Otherwise returns

{default: the module exports}. This is a compatibility for modules that do not have a default export. Fs modules are commonJS and do not have an __esModule attribute, exported using modules.exports. Path_1 in the above code is actually {default:module.exports}, so path_1.default points to the original path module, so you can see that the conversion is normal.

There is a catch with this approach. For example, if you have a third party module whose file is either Babel orts converted, it is very likely that the module code contains an __esModule attribute but does not export exports. Default. Default points to undefined. What’s more, the IDE and compiler reported no errors. If this basic type checking doesn’t work, why do I need TypeScript?


Fortunately, tsconfig provides a configuration allowSyntheticDefaultImports, allow never set the default default import export modules, it is important to note that this property does not have any influence on code generation, just silently. Also, when configuring “module”: “Commonjs”, its value is and esModuleInterop synchronous, which means we set up in front of the “esModuleInterop” : true, equal to at the same time set up a “allowSyntheticDefaultImports” : true. The permission is not to prompt.


After manually modify “allowSyntheticDefaultImports” : false, will find that ts file import path from ‘path’ place prompted module “” path” “there is no default exported. Ts (1192), with this prompt, is changed to import * as path from path to avoid the above trap.


For example, 🌰

Take the lensing system that’s being done right now



1 Import all modules in es6 module format only import * as path from ‘path’/import {resolve} from ‘path’

This can be resolved by adding esModuleInterop”:true


2 Lazy loading is not supported

1 Modify ts.config to configure “module”: “esnext”,

Upgrade typescript”: “^3.4.5” to typescript 3.74


Here is a brief analysis of lazy loading

React. Lazy implements lazy loading and is eventually compiled into import(), which is supported only by the ES6 module.

Ensure is commonly used to implement lazy loading (this syntax is no longer recommended in the new webPack) and actually relies on the CommoJs-enabled syntax provided by WebPack.

React: module.esNext: module.esnext



The next installment will talk about webPack code optimization, CMD specification + JSONP implementation of asynchronous download mechanism