-
Notifications
You must be signed in to change notification settings - Fork 19
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
Display user feedback when IPFS fails to provide annotations #3396
Conversation
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.
@danbr Here are the paddings from the design. 14px left and right, 24px top and bottom. |
ebad860
to
ec98a50
Compare
@arrenv After a little more finessing..... |
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 good to me! The padding looks better and better aligns with the design.
Confirming that we discussed the difference in the paddings and line heights. So, we aimed to match the height of the whole element. Which, made the padding top and bottom 20px
to={location.pathname} | ||
text={MSG.reloadLink} | ||
className={styles.link} | ||
onClick={() => window.location.reload(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.
This doesn't need false
, right?
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.
@arrenv correct. Its superfluous - I will remove.
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.
Very nice work on how you manage the reusability of the component.
You just need to implement one change - as per my comment for the CalloutCard
component.
@@ -0,0 +1,34 @@ | |||
.main { | |||
padding: 20px 14px 20px 14px; |
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.
you can just do padding: 20px 14px
return ( | ||
<div className={getMainClasses(appearance, styles)}> | ||
<FormattedMessage {...label} values={labelValues} /> | ||
<FormattedMessage {...description} values={descriptionValues} /> |
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.
Both for label
and for description
your types give string
as an option and you can't destructure a string. You either need to change types to restrict it to only MessageDescriptor
, or you call it depending on what type the prop is (similar to some other core components)
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 you should make them a MessageDescriptor
required type. I'm not seeing this being used with simple strings anyway
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.
Other than what the others said, I'm good with this.
@@ -0,0 +1,61 @@ | |||
**Description** |
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.
Very cool of you to add a styleguide entry for this, but I think we're going to discontinue this. (unless you guys have other opinions on this)
Leave it in for now
return ( | ||
<div className={getMainClasses(appearance, styles)}> | ||
<FormattedMessage {...label} values={labelValues} /> | ||
<FormattedMessage {...description} values={descriptionValues} /> |
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 you should make them a MessageDescriptor
required type. I'm not seeing this being used with simple strings anyway
|
||
const annotationMessage = getAnnotationMessage(); |
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.
Maybe add a spinner loader while trying to fetch / parse the IPFS hash (and subsequent object)
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.
All good - nice work!
Description
This PR displays a warning to update the user when IPFS is uncontactable and does not return annotations for the annotation hash provided.
No IPFS connection:
With IPFS connection:
To promote simplification and standardisation, I have created a CalloutCard component to display the message. This new generic component is very configurable and can be used in exiting situations, such as Confusable warnings ( i will create a new issue to search & replace), and should be considered for use in new dev.
Resolves #3237