-
Notifications
You must be signed in to change notification settings - Fork 55
Conversation
06d915c
to
f92ef7c
Compare
8adbc0a
to
fab102f
Compare
a4cb6b6
to
dcac475
Compare
dcac475
to
4e3dd5d
Compare
}), | ||
|
||
description: ({ props, variables }: StyleParam): ICSSInJSStyle => ({ | ||
opacity: 0.5, |
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.
Can you remove this? We don't want opacity set for the description...
}), | ||
|
||
progress: ({ props, variables }: StyleParam): ICSSInJSStyle => ({ | ||
transition: 'width 0.2s', |
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.
looks like the animation's working!
|
||
icon: ({ props, variables }: StyleParam): ICSSInJSStyle => ({ | ||
flex: '0 0 auto', | ||
marginRight: variables.iconSpace, |
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 don't want this margin since the attachment's 8px padding is enough to get this icon in the correct place.
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 between the icon and the header/description. I believe the redline called for a larger value here.
fitted: true, | ||
}, | ||
})} | ||
</div> |
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 am wondering if this is the best approach, adding div's for handling our styling. I don't see a way how can the user alter these, unless using CSS selectors. I had similar propose #199 (comment) but I don't think thins should be the general approach when defining shorthands (see the comments below). What are your thoughts on this @levithomason ?
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.
@mnajdova, sorry, but just to be sure - does your comment above, essentially, attribute to the problem of customizing slot's tree (the one that referenced issue is about)?
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, exactly. Not strictly for this component, but just as e reference to the RFC about the customizing of the slot's tree.
import ComponentExample from 'docs/src/components/ComponentDoc/ComponentExample' | ||
import ExampleSection from 'docs/src/components/ComponentDoc/ExampleSection' | ||
|
||
const Slots = () => ( |
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.
one thing that am thinking about - probably, it would be nice it we would come up with some general logic of presenting these slots in a way that those will be more visible to the client
examplePath="components/Attachment/Slots/AttachmentIconExample" | ||
/> | ||
<ComponentExample | ||
title="Header" |
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.
header is advertised as slot, and maybe I've made a false conclusion from it, but the first thing I've tried was the following - essentially, one of those things that we might expect from the shorthands:
<Attachment header={{ content: '...', styles: { color: 'red' } }} />
Apparently, it doesn't work. So, the question is the following: do we see this general pattern (that is applicable for shorthands) to be applicable to any slot content? Actually, more interested about our vision on that.
To me it seems to be a very good thing to ensure this consistency in our customization mechanisms - especially given that the following approach for style tweaking seems to be deprecated:
<Attachment styles={{ header: {..<header styles>..} }}
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.
@brianespinosa, sorry for the late response, my bad :( my promise to be better next time.
Unfortunately, now - and the reason is that header
is currently introduced as a simple string
, and not a Stardust component that encapsulates this knowledge on how this styling should be applied.
However, this is quite easy to fix - we could use Text
component for header
and content
, so that all functionality of slots (where main aspect is styling) will be preserved.
<ExampleSection title="Variations"> | ||
<ComponentExample | ||
title="Actionable" | ||
description="An Attachment can be styled to indicate possible user interaction." |
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.
not sure, but maybe we could better advertise to the user that this (and couple of other ones) example is clickable - frankly, was able to infer this fact only by looking on the code :)
Codecov Report
@@ Coverage Diff @@
## master #220 +/- ##
==========================================
+ Coverage 92.19% 92.36% +0.16%
==========================================
Files 61 63 +2
Lines 1127 1152 +25
Branches 147 173 +26
==========================================
+ Hits 1039 1064 +25
Misses 84 84
Partials 4 4
Continue to review full report at Codecov.
|
lets address pending comments that were left for already provided functionality, and merge this PR afterwards. After that there will be additional PR to solve the rest two requirements:
Will take care of that. |
{(header || description) && ( | ||
<div className={classes.content}> | ||
{Text.create(header, { | ||
defaultProps: { |
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.
+1
Attachment
An Attachment displays a file attachment.
TODO
API Proposal
This PR is implementing the Attachment component from stardust-ui/specifications#1. The latest Teams theme redlines were used. Sizes, spacing, colors, and states are redline correct for this version of the component.
The markup includes a div for each slot. This makes flexbox and css grid layouts easier.
Actionable
This prop styles the component to appear actionable by the user. A pointer cursor is used and a hover color is applied.
Things to know
action
slot was used instead. The render prop callback can be used to provide a button group if the user wishes.