Skip to content
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

Merged
merged 3 commits into from
Oct 24, 2016

Conversation

ahmedlhanafy
Copy link
Contributor

No description provided.

@ahmedlhanafy ahmedlhanafy mentioned this pull request Oct 24, 2016
Closed
import fonts from '../styles/fonts';
import withTextProps from './withTextProps';

const Subheading = withTextProps(fonts.regular, 12);
Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Member

@satya164 satya164 Oct 24, 2016

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);

Copy link
Contributor Author

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 👍

Copy link
Member

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.

Copy link
Member

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?

Copy link
Contributor Author

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';
Copy link
Member

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

Copy link
Contributor Author

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?

Copy link
Member

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

Copy link
Contributor Author

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,
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@satya164

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

Copy link
Member

Choose a reason for hiding this comment

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

@ahmedlhanafy

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@satya164 For the disabled text here check this link and see how it's used.
we can rename it to textColor and secondaryTextColor

Copy link
Member

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

Copy link
Member

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?

Copy link
Member

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

Copy link
Contributor Author

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 */
Copy link
Member

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';
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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

Copy link
Member

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.

Copy link
Contributor Author

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

@satya164 satya164 merged commit 28313b2 into master Oct 24, 2016
@satya164 satya164 deleted the text-component branch October 24, 2016 14:04
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.

None yet

2 participants