键入ANY不能分配给类型从未分配。 (将索引签名添加到接口之后)

发布于 2025-01-24 13:58:21 字数 1291 浏览 1 评论 0原文

HI SO II AM获得以下函数的关注错误:

函数:

        await AutoUsersPositions.updateOne(
            { user: userSetup.userEmail },
            { $push: { stocks: { id: position._id, active: true, createdAt: Date.now()} } }
        )

错误:

 Type 'any' is not assignable to type 'never'.
Type 'boolean' is not assignable to type 'never'.
Type 'number' is not assignable to type 'never'.

第一个错误分配给第2个单词“ ID”是“ active”,第三个错误是“创建”

此集合的界面:

const AutoUsersPositionSchema = new Schema({ //סכמה משתמש
    user: String, 
    userID: String,
    stocks: Array,
    bonds: Array, 
    comodity: Array, 
    currencyPairs: Array, 
    indexes: Array, 
}, { collection: "AutoUsersPositions"} );

export interface AutoUsersPositionsDocument extends Document {
    user?: string,
    userID?: string,
    stocks?: [id: any, active: any, createdAt: any],
    bonds?: [id: any, active: any, createdAt: any],
    comodity?: [id: any, active: any, createdAt: any],
    currencyPairs?: [id: any, active: any, createdAt: any],
    indexes?: [id: any, active: any, createdAt: any],
    id? : any,
    active?: any,
    createdAt: any,
    [key: string]: any

}

当我添加[key:string]:任何内容(我不想删除此问题)之后,问题开始发生。有什么想法要解决这个问题吗?

hi so i i am getting the follow error for the follow function:

function:

        await AutoUsersPositions.updateOne(
            { user: userSetup.userEmail },
            { $push: { stocks: { id: position._id, active: true, createdAt: Date.now()} } }
        )

errors:

 Type 'any' is not assignable to type 'never'.
Type 'boolean' is not assignable to type 'never'.
Type 'number' is not assignable to type 'never'.

the first error is assigned to the word "id" the 2nd is to "active" and the 3rd one is to "createdAt"

my interface to this collection:

const AutoUsersPositionSchema = new Schema({ //סכמה משתמש
    user: String, 
    userID: String,
    stocks: Array,
    bonds: Array, 
    comodity: Array, 
    currencyPairs: Array, 
    indexes: Array, 
}, { collection: "AutoUsersPositions"} );

export interface AutoUsersPositionsDocument extends Document {
    user?: string,
    userID?: string,
    stocks?: [id: any, active: any, createdAt: any],
    bonds?: [id: any, active: any, createdAt: any],
    comodity?: [id: any, active: any, createdAt: any],
    currencyPairs?: [id: any, active: any, createdAt: any],
    indexes?: [id: any, active: any, createdAt: any],
    id? : any,
    active?: any,
    createdAt: any,
    [key: string]: any

}

apprenatly the problem started happening after i added [key:string]: any (i dont want to delete this). any ideas how to fix this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

静若繁花 2025-01-31 13:58:21

This can be simplified to:

interface Stock {
  id: any
  active: any
  createdAt: any
}

interface Foo {
    stocks?: Stock[]
    [key: string]: any
}

const foo: Foo = {
    stocks: [{
        id: 1,
        active: true,
        createdAt: Date.now()
    }]
}

console.log(foo)

According to the playground the基本结构效果很好。您的类型定义非常自由,可能没有太大帮助,但我想您正在努力缩小类型的定义。

我怀疑问题在于实施猫鼬函数及其如何确定类型(您提供的自由定义可能没有帮助)。

添加访问者类型([键:字符串]:任何)似乎对操场的可接受性没有任何影响,并且仅用于削弱属性定义(即stocks是指定形状的可选,可以是任何),这很可能会弄乱蒙古斯(Mongoose)的类型解释。您为什么认为您需要该登录器定义?

This can be simplified to:

interface Stock {
  id: any
  active: any
  createdAt: any
}

interface Foo {
    stocks?: Stock[]
    [key: string]: any
}

const foo: Foo = {
    stocks: [{
        id: 1,
        active: true,
        createdAt: Date.now()
    }]
}

console.log(foo)

According to the playground the basic structure works fine. Your type definition is very liberal and probably not much help, but I imagine that you are working towards narrower type definitions.

I suspect that the problem lies in the implementation of the Mongoose function and how it determines type (which might not be helped by the liberal definition you are giving it).

Adding the accessor type ([key: string]: any) doesn't seem to make any difference to the playground acceptability, and only serves to weaken the property definitions (i.e. stocks is optional of a specified shape, AND it can be any) which might well be messing up Mongoose's interpretation of type. Why do you think you need that accessor definition?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文