简体   繁体   English

元素隐式具有“ any”类型,因为类型“ xxx”没有索引签名

[英]Element implicitly has an 'any' type because type 'xxx' has no index signature

I encounter two case about this problem when I try to refactor a es6 project in typescript, and one is about Object.keys() and the other is about import * as xxx . 当我尝试在打字稿中重构es6项目时遇到两种有关此问题的情况,一种是关于Object.keys() ,另一种是关于import * as xxx

Case 1: 情况1:

const SUPPORTED_VALUES = {
    min_s: 'Mininum similarity',
    max_rc: 'Maximum result count'
}
const UNSUPPORTED_MSG =
    'Configurable values:\n' +
    Object.keys(SUPPORTED_VALUES)
        .map(k => `${k}: ${SUPPORTED_VALUES[k]}`)
        .join('\n')

The k in the map is guaranteed to be a key in SUPPORTED_VALUES , but typescript compiler doesn't know about this. mapk保证是SUPPORTED_VALUES的键,但是Typescript编译器对此一无所知。 How should I fix this without disabling noImplicitAny ? 如何在不禁用noImplicitAny情况下解决此noImplicitAny

Case 2: 情况2:

I have a file called cmd.ts : 我有一个名为cmd.ts的文件:

export async function cmd1(args){}
export async function cmd2(args){}

It is used is another file like this: 使用的是另一个这样的文件:

import * as cmdHandlers from './cmd'
// some code...
if (cmd in cmdHandlers) {
    await cmdHandlers[cmd](bot, msg, ...args)
}

This is also guaranteed that cmd exists in cmdHandlers , but typescript compiler can't handle this. 这也可以确保cmdHandlers存在cmd ,但是打字稿编译器无法处理此问题。

In case 1, you need define exactly type for SUPPORTED_VALUES like {[key: string]: string} 在情况1中,您需要为SUPPORTED_VALUES准确定义类型,例如{[key: string]: string}

const SUPPORTED_VALUES: {[key: string]: string} = {
  min_s: 'Minimum similarity',
  max_rc: 'Maximum result count'
}
const UNSUPPORTED_MSG =
  'Configurable values:\n' +
  Object.keys(SUPPORTED_VALUES)
    .map(k => `${k}: ${SUPPORTED_VALUES[k]}`)
    .join('\n')

Case 2, The same case 1, cmd can be anything, but cmdHandlers only includes cmd1 and cmd2 . 情况2,与情况1相同, cmd可以是任何东西,但cmdHandlers仅包括cmd1cmd2 You can define your type for cmd.ts module to make cmdHandlers is a object with any property name. 您可以为cmd.ts模块定义类型,以使cmdHandlers是具有任何属性名称的对象。

I think it is ok, because you have a condition before call a function 我认为可以,因为在调用函数之前您有条件

// cmd.ts // cmd.ts

async function cmd1(...args: any) { }
async function cmd2(...args: any) { }

const myExport: { [key: string]: (...args: any) => void } = {
  cmd1,
  cmd2,
}

export default myExport;

// //

import cmdHandlers from './cmd'
// some code...
if (cmd in cmdHandlers) {
    await cmdHandlers[cmd](bot, msg, ...args)
}

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 元素隐式具有'any'类型,因为类型'xxx'没有索引签名.ts(7017) - Element implicitly has an 'any' type because type 'xxx' has no index signature.ts(7017) element隐式具有“any”类型,因为类型“{0}”没有索引签名 - element implicitly has an 'any' type because type '{0}' has no index signature 打字稿:可能导致此错误的原因是什么? “元素隐式具有'任意'类型,因为类型'对象'没有索引签名” - Typescript: what could be causing this error? “Element implicitly has an 'any' type because type 'Object' has no index signature” 元素隐式地具有“ any”类型,因为索引表达式不是“ number”类型 - Element implicitly has an 'any' type because index expression is not of type 'number' 元素隐式具有“任何”类型,因为“任何”类型的表达式不能用于索引类型 - Element implicitly has an 'any' type because expression of type 'any' can't be used to index type TypeScript 错误:“元素隐式具有 'any' 类型,因为类型 'any' 的表达式不能用于索引类型 - TypeScript Err: "Element implicitly has an 'any' type because expression of type 'any' can't be used to index type TypeScript - 元素隐式具有“任何”类型 [...] 在类型上未找到具有“字符串”类型参数的索引签名 - TypeScript - Element implicitly has an 'any' type [...] No index signature with a parameter of type 'string' was found on type 元素隐式具有“任何”类型,因为“字符串”类型的表达式不能用于索引类型“BGColors” - Element implicitly has an 'any' type because expression of type 'string' can't be used to index type 'BGColors' 元素隐式具有“any”类型,因为“number”类型的表达式不能用于索引类型“{}” - Element implicitly has an 'any' type because expression of type 'number' can't be used to index type '{}' 元素隐式具有“任何”类型,因为“字符串”类型的表达式不能用于索引类型“{}” - Element implicitly has an 'any' type because expression of type 'string' can't be used to index type '{}'
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM