-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sub-component style support in mergeStyleSets #5513
Sub-component style support in mergeStyleSets #5513
Conversation
@@ -1 +0,0 @@ | |||
export type IClassNames<T> = { [key in keyof T]: string }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to major bump @uifabric/utilities
because of this change. IClassNames simply doesn't make sense now (semantically wrong, in addition to structurally wrong) because it doesn't just have classnames...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pull master
resolve "object" error
resolve typing issue
…c-react into cliffkoh/styleFunctionsV2
getDefaultStyles(styleProps), | ||
getStyles && getStyles(styleProps) | ||
); | ||
const classNames = getStyles |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LOOKS cleaner - but is there something fundamentally wrong with having a null as a 2nd param?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a type error.. I didn't change this because I was too free 😁
example-app-base
could use a lot of work to get spruced up to modern standards. In modern standards, we don't call mergeStyleSets
from components but we call classNameFunction
/getClassNames
instead. dzearing asked me to do the bare minimum though and to invest my time in Dropdown conversion instead.
|
||
/** | ||
* Combine a set of styles together (but does not register css classes). | ||
* @param styleSet1 The first style set to be concatenated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@param styleSet
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
styleSet6: TStyleSet6 | false | null | undefined | ||
): IConcatenatedStyleSet<TStyleSet1 & TStyleSet2 & TStyleSet3 & TStyleSet4 & TStyleSet5 & TStyleSet6>; | ||
|
||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't know if my eyes are playing tricks on me but is this the same as the implementation below?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it is the same.
@@ -14,7 +14,7 @@ export class ButtonSplitExample extends React.Component<IButtonProps> { | |||
const { disabled, checked } = this.props; | |||
|
|||
const getClassNames = classNamesFunction<IButtonBasicExampleStyleProps, IButtonBasicExampleStyles>(); | |||
const classNames = getClassNames(getStyles); | |||
const classNames = getClassNames(getStyles, {}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that {}
is needed - the definition of getClassNames already defaults to {}
for you...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, initially I didn't allow it but David decided to keep it optional for backwards compatibility. The original version would have been undefined. My POV is that if you don't need style props, you should just pass in a style object and so all style functions should take in the 2nd arg.
@@ -1,4 +1,6 @@ | |||
{ | |||
"extends": ["office-ui-fabric-react-tslint"], | |||
"rules": {} | |||
"rules": { | |||
"no-any": false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could just do tslint:disable:no-any
like the other places
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My POV is that this library in particular has a high density of real, unavoidable uses of any (the implementation function in the overloads, for instance). Having a ton of tslint:disable scattered around is a big mess.
We still disallow implicit anys, and any use of any
will be scrutinized.
// However, because we usually use `props.styles` as the argument to an invocation of this method, and | ||
// `props.styles` itself is defined as optional, this avoids the need to use `!` at all invocation points. | ||
if (styleFunctionOrObject === undefined) { | ||
// throw new TypeError( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove commented code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm I already did - must have forgotten to push 😅
/** | ||
* A concatenated style set differs from `IStyleSet` in that subComponentStyles will always be a style function. | ||
*/ | ||
export type IConcatenatedStyleSet<TStyleSet extends IStyleSet<TStyleSet>> = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no difference between this and IProcessedStyleSet... I'm thinking about whether we gain much in differentiating them. The difference is that mergestyleset has a side effect of registering them but concat doesn't. The result is the same type structurally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a difference, look closely.
One contains classnames, one contains IStyles.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not just specified in the code, but called out in the comments as well. :)
@kenotron Appreciate if you could review the changes to DetailsRow in 97e4fd4 (part of this PR) and sign off on it by approving the PR. There's technically a breaking change in #5514 which you're also doing because we're removing a prop... @Vitalius1, do you know why there is another copy of Shimmer in experiments? Should we be de-duping? @JasonGore appreciate if you could sign off on the createComponent changes in experiments too. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes work in DetailsRow I believe.
@cliffkoh The Shimmer from experiments can not be removed as of now as it's being used in |
Signing off from ChoiceGroup perspective. #Resolved |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is awesome!
}; | ||
|
||
/** | ||
* A processed style set is one which the set of styles associated with each area has been converted |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
// It might not be necessary once Omit becomes part of lib.d.ts (when we remove our own Omit and rely on | ||
// the official version). | ||
// tslint:disable-next-line:no-any | ||
return concatStyleSets(...(result as any)) as IConcatenatedStyleSet<TStyleSet>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could it be related to this? I feel like I had a similar issue.
Pull request checklist
$ npm run change
Description of changes
Support passing in a stylefunction or object to subcomponent styles (in a new way that doesn't require conditional types).
Substantially improve typings which results in way better intellisense, and more errors being caught.
Very rough example of what you can do now in a
.styles.ts
A user calling the component can then pass in:
Focus areas to test
(optional)
Microsoft Reviewers: Open in CodeFlow