-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
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
[Subheader] new Component (Recover 2979) #3033
Conversation
inset: false, | ||
}; | ||
|
||
let Subheader = ({children, muiTheme, inset, style, ...other}) => { |
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 use a props
variable here. That will be better for adding new property.
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.
@oliviertassinari ok, but let's agree on one style for single arguments in lambdas (props) =>
or props =>
?
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.
That's a tough question 😁. I would say (props) =>
for when we add a new parameter in the future.
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.
Ok then it's settled 😆 😆
Should I add a documentation page for this too? ( I'm in for adding a page rather than random mentions on other components) Maybe a new section where this and divider and it's kind could go under? Something like: Miscellaneous, or Utility, or... I don't know! naming is NP-Complete in my book :| |
@pradel Sorry, I'm intercepting your PR. this was the best way I could get it back up and running so we can have it in the next release. |
@@ -101,6 +101,7 @@ const GridList = React.createClass({ | |||
const mergedRootStyles = this.mergeStyles(styles.root, style); | |||
|
|||
const wrappedChildren = React.Children.map(children, (currentChild) => { | |||
if (currentChild.type.displayName === 'Subheader') return currentChild; |
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.
currentChild
and currentChild.type
can be null or undefined.
What about using React.isValidElement
like in TableRow?
Or
if (!currentChild) {
return null;
}
if (!currentChild.type) {
return currentChild;
}
like in ToolbarGroup?
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.
React.isValidElement
seems more convenient, no?
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.
Alright, the implementation looks good: https://github.com/facebook/react/blob/master/src/isomorphic/classic/element/ReactElement.js#L283.
@alitaheri I guess one option is just import examples from List and Grid (and eventually Menu) that use Subheader and write a different description name for it? I don't know if it's better to rewrite new and possibly redundant examples |
@newoga That's one possibility, I like it 😁 @oliviertassinari What do you think. Also, how about putting this and Divider under some section with some name? since these are general and are mostly used by our own components. Something like Miscellaneous, or Utility, etc. |
Build fails because of jsx-eslint/eslint-plugin-react#408. I'm investigating. |
Using examples in two different page sounds like a good idea.
I'm not sure, what would be the benefit? If it's for reducing the length of the LeftNav list. We can merge the |
Well the length doesn't matter, besides the flatter they are the easier it is to find components.
That would make it hard to find these since Picker has neither Time not Date 😁 I'm just thinking out load. I don't see any benefit myself. And if it's ok with all, I'll just make a Subheader Page :P |
But, this is what Google is doing. Are you criticizing their website 😁 ? https://www.google.com/design/spec/components/pickers.html |
@oliviertassinari Yes actually 😆 😆 Because it took me some time to find the |
I'll let you two fight and agree with whoever is still alive 😨 😆 I'm fine with the Subheader page, I think it might make sense to generally follow the spec layout. We may regret it one day but it's worth trying haha. |
😆 😆 😆
Alright then I'll work on it tomorrow. it's 1:44 AM here. 😪 😪 |
@alitaheri Thanks a lot it's all there :) |
I like the idea of grouping the form components together - 'switches' by itself always felt unnatural to me, but in that case, the "pickers" are also form components. That doesn't solve the problem of where to put utility components however. (I'd throw |
@alitaheri Arguably also |
5516b68
to
05c04d1
Compare
Guys take another look at this. @pradel I hope this is how you hoped it would turn out 😁 @oliviertassinari @newoga Take a look at the docs. I don't know it the titles are right. @mbrookes Let's discuss categorization in it's own issue. It's very debatable 😆 I personally think P.S. I had to implement a way to be able to ignore certain props. see if it's all good. I think Almost forgot. I also deprecated subheader props of list 😆 |
@@ -28,7 +28,7 @@ import ListExampleSelectable from './ExampleSelectable.jsx'; | |||
|
|||
const descriptions = { | |||
simple: 'A simple `List` with left and right [SVG icons](/#/components/svg-icon).', | |||
chat: 'A chat list with Image [Avatars](/#/components/avatar) and List `subheaders`.', | |||
chat: 'A chat list with Image [Avatars](/#/components/avatar) and `Subheader`.', |
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 supposed we might as well link to the subheader docs since we're doing it with Avatars here. Thoughts?
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.
Yeah, good idea 👍 👍
I think i'm good with this other than the few debatable comments I made.
I like deprecating and simplifying, but should we just add this the the list of things we should deprecate in (I'm all for documenting the new way of doing it though) |
@newoga I'm not going to merge this before the 0.14.3 release. For the exact same concern 😁 |
Sounds good! |
@@ -12,7 +12,7 @@ import gridListExampleComplexCode from '!raw!./ExampleComplex'; | |||
import GridListExampleComplex from './ExampleComplex'; | |||
|
|||
const descriptions = { | |||
simple: 'A simple example of a scrollable `GridList`.', | |||
simple: 'A simple example of a scrollable `GridList` containing a `Subheader`.', |
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.
Should that perhaps link to the Subheader docs page?
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, we discussed it for some other places too. I'll provide links in my next commit 😅 😅
Having this many collaborators is awesome! Thank you all for your magnificent feedback 🙏 🙏 |
Sorry for all the pings 😁 @mbrookes @oliviertassinari @newoga Take a final look 😄 |
Looks good here. (Unless you wanted to add it to the change log as part of the PR...) |
I'm usually the one who updates the change log for a release, so no difference 😁 |
hasSubheader = true; | ||
} else { | ||
const firstChild = React.Children.toArray(children)[0]; | ||
if (React.isValidElement(firstChild) && firstChild.type === Subheader) { |
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.
Interesting, I didn't realize child.type === Subheader
worked. Is there a reason why we're not using this patter over using displayName
everywhere else in the codebase?
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.
No idea O.o
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.
Oh yeah, I'm really interested in removing the use of displayName
for the check. Then, I would be able to write a plugin that remove the displayName from the production build 😁
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.
Good to know...will watch out for areas we're doing this. This approach is a lot better/safer IMO.
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.
Actually, I see one drawback here. We end up importing the <Subheader />
component even if we don't need it.
What about using displayName
😁?
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.
@oliviertassinari I'm gonna make an issue for this kind of things so we can fully discuss what we should do 👍 Thanks for pointing it out
@alitaheri This looks good to me too! 👍 |
I know - but saw you added a HEAD section... |
Yeah, actually I proposed a note to be added somewhere to ask contributers to add a line there. but the I realized it's harder this way with a lot of overhead (how to write it, what to add what not to add, etc...) So I decided it's just easier to build it up from the git log ( github helps a lot). So I don't bother doing it my self either. since I'll do it all at once with more concentration. @newoga Yeah, I think you're right. might not be a bad idea to continue that in another issue. 😁 |
@alitaheri makes sense. |
Let's not merge this just yet 😁 we should wait for the 0.14.4 release. |
c199839
to
cd6c96d
Compare
@oliviertassinari It's done. feel free to merge if all's good. thats 😁 |
[Subheader] new Component (Recover 2979)
@pradel @alitaheri Thanks, that's a great addition to the lib 👍! |
Thanks a lot @pradel This was a great step toward composable components 👍 🎉 |
🎉 Thanks @pradel! Thanks @alitaheri for picking this up 😄 |
This is the recovery of rebase-gone-wrong from #2979.
@pradel Is this all of it? Did I miss something? if so, I'll look through the commits again. Just make sure it's all there 😁
@oliviertassinari @newoga @mbrookes Continue reviewing here :D