Skip to content
This repository was archived by the owner on Mar 4, 2020. It is now read-only.

feat(Text): add "me" option to atMention prop#277

Merged
levithomason merged 6 commits intomasterfrom
fix/at-mention-other
Sep 27, 2018
Merged

feat(Text): add "me" option to atMention prop#277
levithomason merged 6 commits intomasterfrom
fix/at-mention-other

Conversation

@codepretty
Copy link
Collaborator

atMention text can be of 2 types, myself or another person

Example
image

Usage

<Text atMention="me">@Mention Me</Text>
<Text atMention="other">@Mention Another</Text>

@codecov
Copy link

codecov bot commented Sep 25, 2018

Codecov Report

Merging #277 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@          Coverage Diff           @@
##           master    #277   +/-   ##
======================================
  Coverage    91.8%   91.8%           
======================================
  Files          63      63           
  Lines        1171    1171           
  Branches      173     152   -21     
======================================
  Hits         1075    1075           
  Misses         92      92           
  Partials        4       4
Impacted Files Coverage Δ
src/components/Text/Text.tsx 100% <ø> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 86101cb...41ddc5c. Read the comment docs.

@kuzhelov
Copy link
Contributor

it seems that at this point we should really be concerned about Teams-domain aspects propagating into core Stardust API. Probably, this is the right point to introduce wrapper for the Text component on the side of Teams, (let me name it TextWrapper), and introduce atMention property with all the necessary values for it

export interface ITextProps {
as?: any
atMention?: boolean
atMention?: 'me' | 'other'
Copy link
Member

Choose a reason for hiding this comment

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

I would think that we would still support the boolean case here. Some themes (like GitHub) don't have the concept of me vs other. In those cases, themes have the need of styling based on the presence of this prop alone (boolean).

<Text atMention>@someone</Text>
<Text atMention="me">@me</Text>
<Text atMention="other">@other</Text>

What these atMention values look like or whether or not they look different between their usages is up to the theme.

Copy link
Member

Choose a reason for hiding this comment

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

Actually, thinking through #277 (comment) more carefully I think we only need boolean and me, correct? An atMention is a generic mention while atMention="me" is the only specifier needed for custom formatting.


/** Set as @mention Text component */
atMention: PropTypes.bool,
/** An @mention Text component can be formatted for myself mentioned or an other person mentioned */
Copy link
Member

@levithomason levithomason Sep 26, 2018

Choose a reason for hiding this comment

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

Phrasing is a bit odd here. There is no "@mention Text component". There is a "Text component" that can be used to show an "at mention". One potential rewrite here might be:

/**
 * At mentions can be formatted to draw users' attention.
 * Mentions for "me" can be formatted to appear differently.
 */

...(truncated && truncateStyle),
...(atMention && { color: v.atMentionTextColor }),
...(atMention &&
atMention === 'other' && {
Copy link
Member

Choose a reason for hiding this comment

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

I would think that we would want to also handle the boolean case here as the "default" at mention formatting. The exception to the atMention usage would be mentions to me. So my proposal would be the majority case (just a boolean prop) would use the majority styling (other).

atMention === true || atMention === 'other' && ...

color: v.atMentionOtherTextColor,
}),
...(atMention &&
atMention === 'me' && {
Copy link
Member

Choose a reason for hiding this comment

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

No need to check for atMention && first. If there is no atMention then the next logical check atMention === 'me' will fail. It is sufficient to only have this one check.

@levithomason
Copy link
Member

levithomason commented Sep 26, 2018

Updating everyone so we're on the same page:

it seems that at this point we should really be concerned about Teams-domain aspects propagating into core Stardust API. Probably, this is the right point to introduce wrapper for the Text component on the side of Teams, (let me name it TextWrapper), and introduce atMention property with all the necessary values for it

Response: In Bellevue we initially shared these same thoughts. However, after considering the "mention" usage in other chat applications the concept of "my mentions" vs "regular mentions" does exist. Since we already have the atMention prop, we decide it makes sense to allow this distinction at the API level.

Conclusion: At the time of writing, both Prague and Bellevue have been updated on this and we're on the same page as far as accepting these Text changes for now.

Forward thinking: There is probably a refactor warranted to the Text component at some future time as it is currently taking on a lot of responsibility. It is needs to have props for various usages (important, etc) as well as props for utility (fontWeight, etc). However, the atMention prop may very well become a separate component entirely.

@levithomason levithomason changed the title fix(Text): update atMention prop to be a string for atMention other support feat(Text): add "me" option to atMention prop Sep 27, 2018
@levithomason levithomason merged commit 6b33010 into master Sep 27, 2018
@levithomason levithomason deleted the fix/at-mention-other branch September 27, 2018 19:07
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants