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
As of RFC 748 components can declare the blocks they accept and the element they expose, if any.
People who are typechecking their templates will get type errors if they try to use power select and it doesn't declare these things, since power select does need to accept a block (and can accept html attributes).
A minimal version of this change would look something like:
The any isn't ideal, but it's consistent with how the existing PowerSelectArgs are defined (which is that the user's model type is any). A larger change that would address that would make the whole component generic over the type of the user's model, so that @options is a T[], @selected is a T, the default block yields a T, and so on.
The text was updated successfully, but these errors were encountered:
@ef4 this should be fixed with next version. While update the addon to v2 we have added missing properties and with latest 2 PR we have fixed the rest.
I know that there are a lot of "any" in interface, maybe we can fix that in the future step by step
As of RFC 748 components can declare the blocks they accept and the element they expose, if any.
People who are typechecking their templates will get type errors if they try to use power select and it doesn't declare these things, since power select does need to accept a block (and can accept html attributes).
A minimal version of this change would look something like:
The
any
isn't ideal, but it's consistent with how the existing PowerSelectArgs are defined (which is that the user's model type isany
). A larger change that would address that would make the whole component generic over the type of the user's model, so that@options
is aT[]
,@selected
is aT
, the default block yields aT
, and so on.The text was updated successfully, but these errors were encountered: