-
Notifications
You must be signed in to change notification settings - Fork 1.4k
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Support React Native easily #600
Comments
100% agree with this approach. |
Sure, want to PR this? also s/Element/Component/ |
The other thing this approach can help with is using the |
It's safe to write only |
There are two another issues for universal react-intl:
Can I send it in one pull request? |
This sort of sucks as it breaks the abstraction.
Can it just be a function that forwards the call onto the |
Which abstraction it breaks? |
As for style inheritance. I think I was wrong. A browser can inherit them and the Text component in React Native inherits as well. http://facebook.github.io/react-native/releases/0.31/docs/text.html#nested-text I had some issues with that, but I need to investigate it more. |
Sebastian has a good talk on this: https://www.youtube.com/watch?v=Zemce4Y1Y-A
Okay that's much better and matches what I remember about React Native. I don't want to introduce a |
I see, still, the text styles seem to be universal among React and React native. But you are right, it could be abstracted. Have you read this awesome article?
http://jxnblk.com/writing/posts/patterns-for-style-composition-in-react/ I think we can reconsider style attribute later, if we will need it. |
Btw, I asked Sebastian Markbåge about that and he promised to respond after a weekend vacation. |
@ericf You could detect if is react-native or not like so: if is react-native, set the "defaultComponent" to |
@AlessandroCorradini that's a decent approach, but we still end up with the issue of needing to specify the use of |
|
@AlessandroCorradini
|
It's my mistake sorry :D I was in a hurry to write. I meant Text component. |
I thought..my approach need dependency with
|
@AlessandroCorradini I don't believe the prop idea is a good approach, because if you intend to create universal apps (using something like react-native-web), you would need to specify the prop every single time you used a react-intl component. It's really best to define the text element to use at the IntlProvider level. The approach that @steida outlined in the first post is the perfect solution, and can easily be adjusted to accommodate SVGs as well, you would just wrap an SVG in another instance of IntlProvider, with textElement='text' or something along those lines. |
I'm agree with you. Now I'm using this custom component to use this library into react-native. It's display a warning but works:
TranslateText.js (Component)
Terms.js (Route)
|
@AlessandroCorradini Remember that browser code can import anything from Native and vice versa. And no, |
+1 @steida |
To augment my +1: it's preferable to NOT detect RN vs ReactJS and automatically decide on the tag to use. RN Docs state that Text formatting is not passed through the tree like in HTML/css and recommends using a customized Text component to guarantee your fonts etc are correct. So, it might be preferable to create AText component that renders the Text with your font preferences, in which case you want AText to be the rendering component for react-intl. |
Any ETA on this one? Is it on the radar or one of those "maybe, if we find some spare time, but probably not" |
You can already use it very easily in React Native, as explained in #119 (comment) |
@brentvatne React Fiber should allow a component's |
I wonder why we're veering of into conceptual idea territory when the initial post in this thread offers a perfect solution. |
@mschipperheyn if you're eager to get the short-term solution in, would you mind opening a PR for it? |
Hi @ericf , I don't have a lot of time but I'll give it a go and see where I end up |
Ok, have a look and tell me what you think: https://github.com/mschipperheyn/react-intl |
@mschipperheyn can you open a PR, even if it's a WIP one? |
Can someone help me test this? Should I deploy as tmp on npm to facilitate? |
I haven't had the time to test this in RN yet and write specific tests for it yet, (I prob will have time over the holidays) but since the changes make the react-intl more generically applicable (not depending on span), without requiring code changes, would it be better if I remove the React Native specific documentation updates, so it can be merged and as such can receive some testing in the wild for RN? |
Ok, so I removed the react-native references from the pull request. My hope is that this makes react-intl usable in React-Native without advertising as such and hopefully generate some useful input from testing in the wild. Also, I hope this will make this merge request acceptable to be applied now instead of later. Basically, the pull request is now "just" a change that eliminates the dependency on 'span' and makes the tag used to encompass the text configurable by specifying a If there are any documentation updates necessary to facilitate the acceptance of this merge request, I'd be happy to make them. |
@ericf can you give me feedback, please? Would love to see this implemented |
This is now in |
I added a note about It would be great if someone wanted to add more comprehensive docs to the Wiki about using with React Native and even including an example app in the repo at |
I already have this ready. I just removed it from the deploy to expedite its release. I will add some stuff |
As a creator of this issue, I changed my mind now. Now I think injectIntl should be used everywhere. It's nice with flowtype checking and auto-complete and definitely less verbose. <FormatWhatever seems to be the unnecessary abstraction for me. Feel free to correct me. |
@steida React Intl's components provide an optimization for re-renders, and a component like |
* Rename some variables * Update flow-typed * Progress * Header, Toolbar * goodness - typed style hoc ftw - note about circular dependencies - refactoring * Fela 0.4 * Fix link for Fela 0.4 * Improve Text.js * OK, I was dumb. * Improve comment * Progress... * Add open-color * progress Need to update to flow 0.35 to continue, because invariants. * Ups * Hooray, thinks are getting shapes - fontSizes and sizes, good to remember - values are reused - <Style /> pattern - etc. * Exact object types, something like immutablejs records Remove unused APP_STORAGE_LOADED action. * Wow, this is it. Exact types with $Keys<T> utility type ftw. - Exact type restricts allowed props, which is the must for good DX. - With $Keys<T>, we can extract keys from any type. - Autocomplete doesn’t work with the {[key: Key]: Bla }, but we don’t need that anymore with exact object type. https://flowtype.org/docs/objects.html#exact-object-types * OK, exact type is not ready yet. Use Exact type instead. - Native exact type doesn’t work with spread nor intersection yet, fortunately we can replace it with custom Exact type. - For Theme, we can’t use native exact type nor Exact type, because the first doesn't support spread nor intersection and the second doesn’t support autocomplete. - For app state, I decided to use Exact anyway, since strictness is more important then autocomplete here. - For Style, I decided to use plain object checking, since we can’t detect custom Fela strings anyway. - Note pattern, plain type A, in export Exact<A>. Why all of that? The simple reason. We want to detect misspelled component props. I we are there :-) I believe this is the best trade-off we can have for now. Of course, there is always room for more strictness. * Box (not finished, but working). Cleaning here and there. * Ook, we have text color. I decided to not allow any open color in color property. Semantic colors should be good enough. Anyone can add new semantic key, or read from theme.colors.open directly in custom components. Tie your hands to free your mind! * Refactor Toolbar to Header It’s a place specific component. * Clean Footer, add semantic tag * Add Paragraph * Allow typed style prop on Box and Text * Add box backgroundColor and border * Remove unimportant implementation details. Yes. H1, H2, P, OL, UL, etc. is just garbage. Not existing in RN anyway. We don’t need it. But we should add accessibility metas, of course. * Improve Box border * Add PageHeader and Heading * Add display to Text * Adjust themes * Add Image component * Simplifying API again Flow inference ftw. * OMG yes, finally working type checking. * $spread instead of ...Foo.style Because …Foo.style() breaks flow check. Also, it’s handy. * progress * Rename style to styled, because potential <Style> clash. * Add back Footer and HomePage * Ok, this is it. Box => Text => Heading Box => Container => Panel * $spread to $extends, it's more familiar. * textAlign and lineHeight belong to Text Add some comments here and there * Add Heading to the theme, chore * Improve Image, fix eslint. * Ad basic flex to Box. Check App.js pattern how to compose Box. * Flex and chore * This is a good pattern. * Collocate props with components * theme.text, leverage defaultProps * Allow style on Box for bypassing. * Omg omg omg * Omg, this is omg. Automatic Vertical rhythm test. * Omg setFontSizeAndRhythmLineHeight * Extract createTypography and chore * Chore * Add superSmall, uses Boxes instead of low level css. I wish I had a better naming * naming is hard * Make Container reusable * progress * Fela "faster than styletron" 4.1.0 * Ok, I don't like const Style = ..., collocating ftw. * Refactor Text instead of writing explaining comments. * Chore * progress - Remove lineHeight tuning from Text, I was wrong. It would destroy multiline texts. We need a better approach. - Box (and text) border must enforce and adjust vertical padding, there is no other way how to compensate rhythm without additional elements. - Improve typography size granularity. Like with monochord, tones must be created by halving. Octave ftw. * Fix rhythm for any border. Add friendly dev warning. Add steps for greater granularity. This is dope shit. * Fix Heading, Padding, add future button example. Plus some fixes here and there. * Improve rhythm warning, allow to suppress it via noRhythm * Ensure vertical rhythm for images * Hmm, consider Size unit for borderRadius and borderWidth as well. * Symmetric steps * Proximity * progress - rename createTheme to configureTheme - Box: use sizes for vertical paddings and margins, and fontSizes for horizontal paddings and margins - reverse typography sizes order, start with the smallest - port fxbml hoc - add Button , not finished yet * progress * progress * Added onClick prop to button and fixed justifyContent prop in Box (#1269) * chore * improve homepage example * Clean BoxProps, type missing prop * Box widths and heights are RhythmOrString as well * Pattern to put space between child Render them as an array and use marginLeft with i && foo * Button, via getPlatformType it's div with tabIndex na role. * Ups * Remove info, only primary, success, warning, danger make sense. * Fix prefixed style types, sort them, add text antialiasing http://usabilitypost.com/2012/11/05/stop-fixing-font-smoothing/ tldr; It’s great, but only for small text with background. Facebook uses it too. * Text antialiasing It fixes Chrome and Firefox on macOS. Edge hasn’t such setting. * Add disabled button * progress - fix eslint - add user-select for themes - disabled button, opacity from theme and tabIndex -1 - chore * chore * improve system font * This Until new flow, we have to type defaultProps manually. * Ok, defaultProps are ok, remove heading bold * Progress * Refactor styled, fix $map. * Fix Box compensate padding * Increase PageHeader Heading size * progress - outline sucks, it’s hard to implement and ugly as well, iOS and medium.com use coloured buttons instead of outlines. Este likes it. - some fixes here and there - improve app header look * Switch theme * Add ToggleBaseline component, add userSelect none to Button * redux-connect 5 * Nice pattern We need ugly blue borders, but with key we can remove them after click via key. Very nice pattern. * Ok, it was pretty stupid idea. * Space on div button dispatches click https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Tec hniques/Using_the_button_role * Chore * Fix eslint and update deps * Fix Image rhythm size * Loading component * UsersPage - remove react-gravatar, use getUserPhotoUrl - update deps (so fast with yarn) - some styling here and there - fixes * Ok, make baseline helper lighter * Tie your hands, free your mind. - em, rem, px, aren’t universal and isolated - having ability to specify em on the box and on the child with another size could lead to nasty inconsistencies - number is like rem, but based on the baseline * Flexbox ftw I just fixed weird vertical space with setting display to flex. It seems that flex should be new a new block. Let’s be explicit for a while, then rethink it. * Update deps * Increase timeout, because life sucks. * Fok deps * Yarn 0.18.1 and updated flow-typed * PageHeader description optional * Update deps * Form component * Input component stub * NewTodo wip * Fix some eslint errrors * wip * Ok, StyledFoo is the pattern. * Update deps * Update static global browser styles We need that for fixing stuff. * Refactor Color types, to get ColorProps for Button primary etc. Also, improve native fontFamily. * Ok, render Button as button for browser. We don't need mapping to div. * This is awesome. We don't need foking defaultProps. The problem I have with defaultProps is, that we can’t read from theme, which sucks socks. With destructuring and default arguments, we don’t need that shit. * wip Going to have a better button api. * Rename type $Exact to $Strict and explain it. Remove comment about callable objects, because we don’t need defaultProps anymore. * Disable eslint react/prop-types, can't detect flow correctly * Clean styled.js * We don't need that anymore. * Improve $extends I wish spread work with flow. Nevermind, this is good enough. * Ok, render button as div again. Render div because button is not consistently rendered across browsers. Looking to you bloody Firefox. * OK, this is it. - Any Text component can have colorProp like primary etc. * Update deps * Chore * Add verticalAlign to Box * Refactor Box border to separate color * Enable remoteHotReload by default * Add tiny color helper library * Input wip * Button wip * Remove unnecessary type annotation * Readability * Aka secondary * wip * Improve fontSmoothing fix * Fix small Button * Fix Text color bug * Active Button state * Move state.themes to state.app where it belongs * Comment * Ratios suck * theme.block.maxWidth * Persist app baselineShown * Finish Input, this is good * Wip * Update deps and flow-typed * /todos done * Rename /* @flow */ to // @flow * OK, never import whole ramda. * OK, FormattedWhatever sucks. Favour injectIntl - injectIntl is reduces boilerplate - it’s already universal - never ever think about what should be user, component or not? - not sure whether React fiber will solve it * The Label * wip * Small tip * Rewrite Input component - multiline - super minimal - error * Remove webkit resizer entirely * wip * Ok, use FormattedXY components. formatjs/formatjs#600 (comment) * FieldsPage wip Add field prop to Input. Why? It looks nicer sure, but also JSX spread breaks flowtype detection. * IntlPage wip * IntlPage * Ramda 0.23 and other deps * Add OfflinePage with Pre component * Add iflow-react-intl, remove Intl type * NotFoundPage * Move SwitchTheme where it belongs * MePage * Reenable no-class-assign, we don't need it with ramda compose * Use field prop We need that because {…for} breaks flow type checking. * Improve Loading, it's text so it's fully syllable * Add disabled state to Input * Port focus HOC helper * Add ugly hack for Form * Almost done SignInPage Need to add SignInError * Add Message component There is a pattern, just Text component with default values. * Flowtype ValidationError I still think that flow typed monad should be better. * Finish SignInPage * Restrict input only for text based fields With text base design, placeholder is required. * FieldsPage wip * Remove old UI, finally. * Fix eslint * This is default now, no need to have it in _config stub * Clean messages * fok
For me, I worked around the issue by calling the
The object passed into
|
I see your points, still. An optimization for re-renders is nice, but it's task for my view component I suppose. Yep, FormattedRelative does sense. FormattedMessage will not work for React Native I guess, feel free to correct me. The reason why I prefer (maybe I am wrong) intl is flow typing. I would love to have typed messages. <FormattedMessage
defaultMessage="Starter kit for universal apps."
id="app.description"
/> How to detect missing message id? It's possible, but it would require a lot of boilerplate I guess. Also, check flow-typed/flow-typed#981 |
It seems const messages = {
"HelloAll": "Hello{all}!"
};
[...]
const allText = <Text>, world</Text>;
[...]
render() {
return <FormattedMessage id="HelloAll" values={{ all: allText }} />;
} It's quite annoying since we have tons of custom Does anyone know if there's another way to achieve this in react-native? EDIT |
@39otrebla can u create a separate issue for tracking? This sounds like a bug. |
I'm not sure this is a bug, It sounds more like a feature request to me. Let me know. |
We do support passing arbitrary objects in (there's no explicit check if it's a React component or anything) so this is a bug to me. Are you using latest react-intl version btw? |
@39otrebla React Native is supported, so it looks like a bug (if you are using a recent version of |
@antoinerousseau @longlho #1430 . Thanks. |
The only problem with usage in React Native is span inside components. React Native needs Text. We can fix it easily. Add textElement into intlConfigPropTypes.
Then all components can use textElement from the context if available.
The text was updated successfully, but these errors were encountered: