linter for useless ref.read

[stephane-archer]

I found in my code a ref.read without a returned value capture:

ref.read(myProvider)

it would be great if Riverpod linter would help detect stupid mistakes like these

[rrousselGit]

Technically that ref.read may not be useless. Some folks use ref.read to eagerly initialize their providers.

I'm not sure whether we'd truly want to ban ""useless"" reads as it's unclear whether they truly are useless or not.
But if we do agree, then adding a @useResult on the method should be enough :)

[stephane-archer]

@rrousselGit can we bypass "@useResult"? That way we can explicitly say that we want that read (probably for initialization purposes)

[rrousselGit]

There's no official way to bypass it, no (besides // ignore: ... but that doesn't count)

[glemartret]

I just looked, adding the @useResult seems indeed a bit strict, it could be useful in the case of a read on a autodisposed provider

[stephane-archer]

"ref.readForInit(myProvider)"
That doesn't return anything
and "ref.read(myProvider)" with "@UseResult"

Would this make sense and make things explicit?

If we have family and auto dispose on the provider, can't we have notLazy to avoid valid use of "ref.read(myProvider)" in the first place?

[rrousselGit]

"ref.readForInit(myProvider)"

I'd rather not add a new API just for that. I'm trying to reduce the API surface, not increase it for very little value.

If we have family and auto dispose on the provider, can't we have notLazy to avoid valid use of "ref.read(myProvider)" in the first place?

Not doable

[stephane-archer]

Do you see any better option than // ignore: useResult I want my provider not lazy ?

[rrousselGit]

Not immediately, and I don't think that's worth the cost either.