TS eslint error, Assert as ({a} or null)

[languid maple]

Hello!

I'm trying to get some data from my redis store.
If I don't assert the value the original type is unknown.

And I know for a fact that it will either return ListBlockChildrenResponse if it exists or null if the value does not exist in the store. And depending on if it exists I'll fetch it from a db and add it to Redis.

const redisData = await kv.hget(redisHashKey, `${redisHashBaseField}:${input.id}`) as (ListBlockChildrenResponse | null)

typescript-eslint is however giving me the following
This assertion is unnecessary since it does not change the type of the expression.eslint@typescript-eslint/no-unnecessary-type-assertion.

And I'm a bit confused why. It was unknown, and now it's asserted as a union of two values.
Would that not change the type of the expression?

[small scaffold]

try hovering over hget and ListBlockChildrenResponse and make sure they're what you expect

[languid maple]

Hget: Redis.hget: <unknown>(key: string, field: string) => Promise<unknown> without as

ListBlockChildrenResponse:

    type: "block";
    block: EmptyObject;
    object: "list";
    next_cursor: string | null;
    has_more: boolean;
    results: Array<PartialBlockObjectResponse | BlockObjectResponse>;
}

Oh I found the initial error now.

(property) Redis.hget: <ListBlockChildrenResponse>(key: string, field: string) => Promise<ListBlockChildrenResponse | null>
When I do the asserition it already expects either ListBlockChildrenResponse | null. So I don't need to add null to assertion and only need to do as ListBlockChildrenResponse

__
However, now it's complaing about the following instead.
Use a ! assertion to more succinctly remove null and undefined from the type.eslint@typescript-eslint/non-nullable-type-assertion-style. Which confused me from the get go.

As I want it to potentially be null.

[small scaffold]

!:thats-no%

[ember wharf]

tjjfvi#0

`!t6:thats-no-generic-its-a-type-cast`:

You can use generics in objects, but usually they should be inferable from the structure of the object.

The classic example of a "misused generic" is a function like:

function getMeA<T>(): T {
   /* magic */
}

Since the generic has no relation to anything in the call signature, it can't be inferred and also there's no way to actually implement that function safely: it's not really a generic, it's a type-cast that's pretending to be a generic.

[stark torrent]

I would recommend that you never use ! in the code unless is strictly necessary, that eslint style rule is pretty bad advice.
And i would also recommend revising that rule or removing it entierly because using ! will eventually cause you problems at runtime

[small scaffold]

your assertion is being inferred as the target for the generic of the function, where it's already being nullable
the intended api here is to pass ListBlockChildrenResponse as the type argument, or use ListBlockChildrenResponse | null as the target type, as in const redisData: ListBlockChildrenResponse | null = ...

[small scaffold]

however, it's using an unsafe pattern. it's not bad, but you should at least be aware of it.

[small scaffold]

that's not what the rule is saying. the rule is saying to prefer x! instead of x as NotNullOfX

it's just a stylistic change, it doesn't check against using an assertion, it just says which kind to prefer

[languid maple]

That did the trick!

To set the target type instead.

[stark torrent]

Gotcha, just now saw it says type.eslint and not typescript eslint 😅

[small scaffold]

type. is the end of the message, eslint is the plugin, @typescript-eslint/non-nullable-type-assertion-style is the error id. it's just all compressed due to the copy/paste.

[stark torrent]

im going to retire, sorry for not adding anything useful to this help request

[small scaffold]

it is @typescript-eslint, just that this rule isn't checking what you think it is
i don't think any rule explicitly recommends !.
some rules recommend as number[] over : number[] for example, but i don't think anything recommends non-nullable assertions; there's just rules that control what kind of assertions are used for stylistic/consistency reasons

this is what the message is supposed to look like fyi @stark torrent

[languid maple]

!resolved