Diretório de artigos
O pano de fundo do surgimento do TypeScript
Pontos de dor de JavaScript
O surgimento de qualquer nova tecnologia é resolver um certo ponto problemático da tecnologia original .
JavaScript é uma boa linguagem de programação?
Todos podem não ter a mesma opinião, mas de muitas perspectivas, JavaScript é uma linguagem de programação muito boa ;
Além disso, pode-se dizer que essa linguagem não será substituída por muito tempo, e será amplamente utilizada em mais campos;
A famosa lei de Atwood :
Jeff Atwood, um dos fundadores do Stack Overflow, propôs a famosa Lei de Atwood em 2007.
Qualquer aplicativo que possa ser implementado em JavaScript eventualmente será implementado em JavaScript.
De fato, vimos que esta frase está sendo cumprida passo a passo :
Sempre usamos JavaScript para desenvolvimento web;
Para desenvolvimento móvel, o desenvolvimento multiplataforma pode ser alcançado com a ajuda de frameworks como ReactNative, Weex e Uniapp, e a tecnologia multiplataforma também usa JavaScript;
O desenvolvimento de pequenos programas também é inseparável do JavaScript;
Podemos desenvolver aplicativos de desktop com a ajuda do Electron;
O desenvolvimento do lado do servidor pode ser feito usando JavaScript com a ajuda do ambiente Node.
E com o rápido desenvolvimento do campo de front-end nos últimos anos, o JavaScript foi rapidamente popularizado e amado pela maioria dos desenvolvedores. Com a ajuda do poder do próprio JavaScript, mais e mais pessoas usam JavaScript para desenvolver .
O bom JavaScript não tem desvantagens?
Na verdade, devido a vários fatores históricos, a própria linguagem JavaScript tem muitas deficiências;
Por exemplo, ES5 e o uso anterior da palavra-chave var sobre o escopo;
Por exemplo, o tipo de array originalmente projetado por JavaScript não é um espaço de memória contíguo;
Por exemplo, até hoje o JavaScript não adicionou o mecanismo de detecção de tipo;
JavaScript está melhorando lentamente
É inegável que o JavaScript está lentamente ficando cada vez melhor, tanto no design de baixo nível quanto no nível do aplicativo.
A introdução de ES6, 7, 8, etc., tornou a linguagem cada vez mais moderna, segura e conveniente.
Mas saiba que hoje o JavaScript ainda não tem progresso na verificação de tipos (por que a verificação de tipos é tão importante, falarei sobre isso mais tarde).
tipo de problema
Antes de mais nada, você precisa saber que temos um consenso no desenvolvimento de programação: quanto mais cedo os erros aparecerem, melhor
Se você encontrar erros ao escrever o código, não os encontre quando o código for compilado (a vantagem do IDE é nos ajudar a encontrar erros durante o processo de escrita do código).
Se você encontrar erros durante a compilação do código, não os encontre quando o código for executado (a verificação de tipos pode nos ajudar a fazer isso muito bem).
Se você pode encontrar bugs durante o desenvolvimento, não encontre bugs durante o teste, e se você puder encontrar bugs durante o teste, não encontre bugs após o lançamento.
Agora o que queremos explorar é como encontrar erros no código durante a compilação do código :
JavaScript pode fazer isso? Não, vejamos os seguintes problemas de código que podem ocorrer com frequência.
// 当前foo函数, 在被其他地方调用时, 没有对参数做任何的校验
// 1> 没有对类型进行校验(字符串或数字都可以传入)
// 2> 没有对是否传入参数进行校验
function foo(message) {
if (message) {
console.log(message.length);
}
}
foo("Hello World");
foo("你好啊TS");
foo() // 错误的调用代码会报错(IDE不会报错), 报错后续代码不会执行
Aqui está um erro muito comum que cometemos :
O grande motivo desse erro é porque o JavaScript não impõe nenhuma restrição nos parâmetros que passamos , e esse erro só pode ser encontrado durante a execução;
E quando esse erro ocorrer, afetará a continuação da execução do código subsequente, ou seja, todo o projeto travará profundamente por causa de um pequeno erro ;
Você pode estar pensando: como eu poderia ter cometido um erro tão baixo?
Quando escrevemos demos simples como o nosso acima, erros como esse são fáceis de evitar e, quando o fazem, são fáceis de verificar;
Mas e quando desenvolvemos um grande projeto? Você pode garantir que você não terá esse problema? E se estamos chamando a biblioteca de classes de outra pessoa, como sabemos que tipo de parâmetros os outros nos permitem passar? Em outras palavras, se você encapsular uma função para outros usarem, como os outros saberão quais parâmetros sua função precisa passar?
No entanto, se pudermos adicionar muitas restrições ao JavaScript, podemos evitar esses problemas no desenvolvimento :
Por exemplo, a mensagem na função que acabamos de passar é um tipo que deve ser passado, se o chamador não passar , um erro será reportado durante a compilação ;
Por exemplo, exigimos que seja um tipo String e, se outros tipos forem passados, um erro será relatado diretamente;
Então você pode saber que muitos erros são encontrados durante a compilação, em vez de esperar para serem descobertos e modificados em tempo de execução;
Já percebemos brevemente alguns dos problemas causados pela ausência de verificação de tipos. Como o JavaScript não considerou restrições de tipo desde o início de seu design, isso fez com que os desenvolvedores de front-end não pensassem em tipos :
Desenvolvedores front-end geralmente não se importam com o tipo de variáveis ou parâmetros.Se o tipo deve ser determinado, muitas vezes precisamos usar vários julgamentos para verificar;
As pessoas que vão para o front-end de outras direções sempre se preocupam que seu código não seja seguro e robusto o suficiente porque não há restrição de tipo;
Portanto, costumamos dizer que JavaScript não é adequado para desenvolver projetos de grande escala, porque uma vez que o projeto é enorme, essa restrição de tipo solto trará muitos riscos de segurança e não há um bom contrato de tipo entre várias pessoas que os desenvolvem .
Por exemplo, quando implementamos uma biblioteca de classes principal, se não houver restrições de tipo, precisamos realizar várias verificações nos parâmetros passados por outros para garantir a robustez do nosso código;
Por exemplo, quando chamamos a função de outra pessoa, a outra parte não comenta a função, só podemos olhar a lógica interna para entender quais parâmetros essa função precisa passar e que tipo de valor de retorno é necessário;
Para compensar as deficiências das restrições de tipo JavaScript e aumentar as restrições de tipo, muitas empresas lançaram suas próprias soluções :
Em 2014, o Facebook lançou o fluxo para verificar o JavaScript;
No mesmo ano, a Microsoft também lançou o TypeScript 1.0;
Ambos trabalham fornecendo verificação de tipo para JavaScript;
E agora, não há dúvida de que o TypeScript ganhou completamente :
No Vue2.x, o fluxo é usado para verificação de tipo;
O Vue3.x mudou para TypeScript em geral, e 98,3% foram refatorados usando TypeScript;
Angular usou TypeScript para refatoração de projetos em um estágio muito inicial e precisa usar TypeScript para desenvolvimento;
E até mesmo alguns produtos do próprio Facebook estão usando TypeScript;
Aprender TypeScript pode não apenas adicionar restrições de tipo ao nosso código, mas também cultivar nossos programadores de front-end com pensamento de tipo .