-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Add different text components and add them in the example app #38
Conversation
import fonts from '../styles/fonts'; | ||
import withTextProps from './withTextProps'; | ||
|
||
const Subheading = withTextProps(fonts.regular, 12); |
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.
Any reason you prefer a HOC here instead of a plain component?
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.
It was a lot of repetitive work when we only need to change the fontFamily
and fontSize
so creating HOC reduces this boilerplate a lot
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.
it's just
const Subheading = props => <StyledText {...props} family={fonts.regular} size={12} />
instead of
const Subheading = withTextProps(fonts.regular, 12);
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 would make more sense 👍
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 like component here just because the props are named unlike function arguments, and we could add more props later rather than adding more arguments which is confusing.
btw just realized, this is not HOC, it's just a function which returns a component.
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.
probably rename it to createStyledText
or something like that. withTextProps
make it sound like an HOC. But it doesn't take a component as an argument, so it is basically creating a new component with the text styles you give. does it make any sense?
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, I knew that the name is misleading couldn't think of a better one at 5:30 in the morning :D
Platform, | ||
} from 'react-native'; | ||
|
||
const isAndroid = Platform.OS === 'android'; |
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 probably be isIOS
, i.e. you set font to helevetica if iOS, other wise sans-serif
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.
Why is that does sans-serif
works on WP?
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.
@ahmedlhanafy it should, it's just system's sans-serif
but my thought was that helvetica is iOS specific, sans-serif isn't android specific, so the other logic makes more sense
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.
Makes sense
} from './colors'; | ||
|
||
export default { | ||
colors: { | ||
primary: indigo500, | ||
primaryDark: indigo700, | ||
accent: pinkA200, | ||
primaryText: black, |
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.
probably we need to think bit more about the naming. We can't name them as primaryText
etc. since it signifies connection with primaryColor
. I guess we also need a primaryText
which will be the text written on a primary
color background (or may be think of a better name).
So probably bodyText
(or even just text
) is a better name?
Where will secondaryText
and disabledText
be used? Generally buttons and controls are disabled, not text?
probably we could just use normal text
color and use opacity when needed instead of adding options in the theme? not sure. I'm saying this because otherwise we'll probably end up adding configs for each component. and people can customize it anyways by passing a style prop to individual 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.
The thing is this is the way MD Docs refers to text in the rest of the docs, primaryText,secondaryText and disabledText. We want to make it easy for people contributing to remember these constants.
I think secondaryText and disabledText have their uses across the docs.
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.
textColor: fullWhite,
secondaryTextColor: fade(fullWhite, 0.7),
This is how MUI is doing it and they have disabled as well, I think this is a better approach than naming things body...etc. It makes things clearer in my opinion
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.
The thing is this is the way MD Docs refers to text in the rest of the docs
I immediately associate it with primaryText
with primaryColor
though
I think secondaryText and disabledText have their uses across the docs
can you give an example, I don't get how a text can be disabled coz it's not an interactive element.
This is how MUI is doing it and they have disabled as well
textColor
is ok, that's why I suggested bodyText
or text
. But I don't wanna put disabledText
in the theme config without having a use case. Probably we should put configs in theme when we start using them?
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.
@ahmedlhanafy Hmm... but then it's not actually disabled text, but anything which is disabled, probably disabledText
isn't the right name
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.
@ahmedlhanafy also what's secondaryText
?
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.
@ahmedlhanafy I think mui is doing it right by naming it as disabledColor
and not disabledTextColor
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.
Check MD Docs you will find references to it.
we can rename it to disabled
instead of disabledText
then
@@ -1,15 +1,19 @@ | |||
// @flow | |||
|
|||
/* @flow */ |
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.
nit: new line after
@@ -3,6 +3,13 @@ | |||
export { default as ThemeProvider } from './src/core/ThemeProvider'; | |||
export { default as withTheme } from './src/core/withTheme'; | |||
|
|||
export * as Colors from './src/styles/colors.js'; | |||
export * as Colors from './src/styles/colors'; | |||
export * as Fonts from './src/styles/fonts'; |
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 we export this? do you see any use case where it'll be used except the default theme?
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 will need it, it's nice to have these constants so that the user can benefit from them.
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.
@ahmedlhanafy can you give an example? I can't think of a case where this will be useful
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.
also people can always access it via the default theme object which we should export, if people wanna make minor changes to default theme.
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 they should use our prebuilt components rather than these constants, I will remove that
No description provided.