Skip to content

feat(Media): add component#94

Merged
eddywashere merged 1 commit intoreactstrap:masterfrom
mking-clari:media
Aug 18, 2016
Merged

feat(Media): add component#94
eddywashere merged 1 commit intoreactstrap:masterfrom
mking-clari:media

Conversation

@mking-clari
Copy link
Copy Markdown
Contributor

@mking-clari mking-clari commented Aug 8, 2016

References #75

Notes

  • The media components are fairly lightweight (almost single class). This is particularly true for MediaHeading and MediaObject.
  • I'm using MediaMarginal for shared code between MediaLeft and MediaRight. It's not intended for direct use by users, but is exposed so we can test it.
  • In MediaList, I'm applying tag="li" to the children. This way, the user of MediaList doesn't have to specify li on each Media item.
  • I'm using Holder to populate placeholder images, similar to the Bootstrap docs. Also, I had to rerun Holder on route update. Without this, if the user goes to /components/media, then /components/buttons, then hits back, the placeholder image isn't populated.

@coveralls
Copy link
Copy Markdown

coveralls commented Aug 8, 2016

Coverage Status

Coverage remained the same at 100.0% when pulling e027e65 on mking-clari:media into 92c62b1 on reactstrap:master.

@coveralls
Copy link
Copy Markdown

coveralls commented Aug 8, 2016

Coverage Status

Coverage remained the same at 100.0% when pulling a65ad60 on mking-clari:media into 92c62b1 on reactstrap:master.

@coveralls
Copy link
Copy Markdown

coveralls commented Aug 8, 2016

Coverage Status

Coverage remained the same at 100.0% when pulling a65ad60 on mking-clari:media into 92c62b1 on reactstrap:master.

Comment thread src/Media.jsx Outdated

return (
<Tag {...attributes} className={classes}>
{left}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This kind of goes against one of the goals for the project. "content is expected to be composed via props.children rather than using named props to pass in Components." Mostly for consistency. Any reason you didn't use a generic Media component for left/right. Placement could be determined by the order it is presented in the markup.

Copy link
Copy Markdown
Contributor Author

@mking-clari mking-clari Aug 13, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I see. Would it look like this?

<Media>
  <MediaLeft ... />
  <MediaBody ... />
<Media>

<Media>
  <MediaBody ... />
  <MediaRight ... />
<Media>

I think if we have a generic component for left/right/body, it's difficult to distinguish children=[left,body] from children=[body,right].

<Media>
  <MediaItem ... /> // left or body?
  <MediaItem ... /> // body or right?
</Media>

Is this what you had in mind for generic Media for left/right, or something different?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about <Media><Media left/><MediaBody/></Media> and <Media right/>

@mking-clari
Copy link
Copy Markdown
Contributor Author

mking-clari commented Aug 14, 2016

@eddywashere I updated the code to use <Media left> and <Media right>.

I think the code would be more consistent with <Media body>, <Media heading>, and <Media object>. What do you think?

@eddywashere
Copy link
Copy Markdown
Member

I think that makes sense <Media body>, <Media heading>, and <Media object>. What about <Media top>, <Media middle>, <Media bottom>? Is that too much?

@mking-clari
Copy link
Copy Markdown
Contributor Author

@eddywashere I agree, I think it makes the usage of the media component easier to remember (more consistent).

@mking-clari
Copy link
Copy Markdown
Contributor Author

@eddywashere I updated the code.

A couple of notes:

  • The default media class is provided by negating all the boolean properties. It's an expression that will need to be updated if there are any new media properties.
  • Currently I have separated Media (body/left/right/heading/object) from MediaList. The reason is that MediaList has special handling for children (setting the tag to be li).

@coveralls
Copy link
Copy Markdown

coveralls commented Aug 17, 2016

Coverage Status

Changes Unknown when pulling 817d8b1 on mking-clari:media into * on reactstrap:master*.

Comment thread src/MediaList.jsx Outdated
<Tag {...attributes} className={classes}>
{React.Children.toArray(children).map((child, i) => {
return React.cloneElement(child, {
key: i,
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about childTag. Would it be better to push people to add <Media tag="li"/>. This seems a little strict by cloning each element inside of MediaList.

@eddywashere
Copy link
Copy Markdown
Member

@mking-clari thanks a ton for this pr and all the updates. I wish I would have had time to do the feedback all at once. I have that one last comment about childTag, let me know what you think. otherwise this looks good to go.

@mking-clari
Copy link
Copy Markdown
Contributor Author

mking-clari commented Aug 18, 2016

@eddywashere thanks for the feedback, I think you've been really helpful and responsive, especially compared to many other github maintainers. I'm happy to contribute a small part to an active repository. The code should be updated with the latest change.

Notes:

  • Now that there's no need for special children handling in MediaList, I combined it with Media.

@coveralls
Copy link
Copy Markdown

Coverage Status

Coverage remained the same at 100.0% when pulling e746f4a on mking-clari:media into 53e285a on reactstrap:master.

@eddywashere
Copy link
Copy Markdown
Member

good call 👍

@eddywashere eddywashere merged commit d4c0f2d into reactstrap:master Aug 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants