You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was trying the new sst startup project which uses electrodb by default for the DynamoDB version and noticed that the type inference of EntityItem in VS Code did not show a readable type:
I needed to inspect this type because it was being reported by intellisense as incompatible with the type expected by the Pothos resolver but the conflict was essentially unreadable because both types were highly generic:
I tried to see why the type inferred from EntityItem could not produce a readable type, and I found that if I reduced all type signatures from <A extends string, F extends string, C extends string, S extends Schema<A,F,C>> to <S extends Schema<any, any, any> and only inferred those types in the types that actually needed them, the tooltip type shown for EntityItem would be a simple type and it would match the type that pothos expects:
So I tried to see why those extra type parameters where needed, and I couldn't find a reason. I even tried to see if I removed them would have any effects in the repository (juanevp@2688d14) but the tests seemed to work alright.
So my question is: why are those type parameters needed? What am I missing?
AFAIK those types are acting only as more rigorous bounds but are redundant with the the bound already in the Schema type.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I was trying the new sst startup project which uses electrodb by default for the DynamoDB version and noticed that the type inference of EntityItem in VS Code did not show a readable type:
I needed to inspect this type because it was being reported by intellisense as incompatible with the type expected by the Pothos resolver but the conflict was essentially unreadable because both types were highly generic:
I tried to see why the type inferred from EntityItem could not produce a readable type, and I found that if I reduced all type signatures from
<A extends string, F extends string, C extends string, S extends Schema<A,F,C>>
to<S extends Schema<any, any, any>
and only inferred those types in the types that actually needed them, the tooltip type shown for EntityItem would be a simple type and it would match the type that pothos expects:So I tried to see why those extra type parameters where needed, and I couldn't find a reason. I even tried to see if I removed them would have any effects in the repository (juanevp@2688d14) but the tests seemed to work alright.
So my question is: why are those type parameters needed? What am I missing?
AFAIK those types are acting only as more rigorous bounds but are redundant with the the bound already in the Schema type.
Beta Was this translation helpful? Give feedback.
All reactions