React native docs #243

vonovak · 2018-07-11T21:54:38Z

No description provided.

tricoder42

This is nice so far! Great work!

tricoder42 · 2018-07-12T05:14:54Z

docs/tutorials/react-native.rst

+
+This was easy. Now, the next step is to translate the ``title`` prop of the ``Button`` component. But wait a sec, the button expects to receive a ``string``, so we cannot use the ``<Trans>`` component here! Also notice the same holds also for the ``Alert.alert`` call.
+
+At this point, we need to turn our attention to the ``@lingui/core`` package, namely the ``setupI18n`` method which can give us an object that we can use like this: ``i18n.t`this will be translated``` and the result of such call is a string. Let's get to it!


This should be actually done using withI18n decorator which injects i18n object to props. I can't believe I haven't mentioned in React docs... I have to update it too. The only mention about this (with short example) is in React API reference. After that, everything is the same.

This should be actually done

sorry, I don't exactly know what you have in mind. Can you take a look at the final code here and perhaps make a PR?

Or do you have this in mind:

<Button onPress={markAsRead} title={i18n.t`mark messages as read`} />

to become

<Button onPress={markAsRead} title={this.props.i18n.t`mark messages as read`} />

?

My idea is to show both translation in react (Trans/ this.props.i18n) and outside of react (i18n.t)

vonovak · 2018-07-13T16:36:03Z

this should be good enough as the first version of the rn docs, can you add your review? Thanks. Btw. the jsx highlighter has some problems with things like "i18n.tblah blah".

also, what branch should I target?

tricoder42

Hey, this is nice work! Use stable-2.x as a base branch and don't worry about conflicts. I'll resolve them manually when the PR is ready.

tricoder42 · 2018-07-16T20:59:18Z

docs/tutorials/react-native.rst

+   },
+  });
+  ...
+  <Button onPress={markAsRead} title={i18n.t`mark messages as read`} />


What I mean here is that you don't need to use setupI18n when you're working with translations inside your components. You need to work with standalone i18n object only outside components, e.g.: in redux-saga actions, etc.

In components, you're better off to wrap you component in withI18n decorator and then you injected i18n prop:

import { withI18n } from '@lingui/react' function MarkAsRead({ i18n, markAsRead }) { return <Button onPress={markAsRead} title={i18n.t`mark messages as read`} /> } // withI18n expects options as a first argument, // so we need to call it with empty parenthesis to get the actual HOC export default withI18n()(MarkAsRead)

okay, gotcha. Then my question is why?

Also, most apps need both - accessing the i18n in components and outside of them - so this approach, if it is valid (?) need to be documented somewhere. I'm okay with using just this.props.i18n.t here because we only deal with components, but then we need to do another guide that will cover using both using i18n.t and this.props.i18n.t and explain why using this.props.i18n.t in components is better that just i18n.t because I'm a lazy person and don't understand why I should use something from props if I can just import a function (i18n.t) and use it everywhere. Hope you understand me. Thanks!

I do. The main reason is re-rendering. When you directly call a function inside a component, the component itself won't re-render when the return value changes because of outside effects.

function TranslatedComponent() { return <span>{i18n.t`Hello World`}</span> }

When you render this component, it will show translation for Hello World. However, when you change the active language, this component will not re-render. This was common issue in react-intl and the only known workaround is to pass key={language} to top-most component and force complete re-render of the whole app.

On the other hand, when you use withI18n decorator:

const TranslatedComponent = withI18n()(({ i18n }) => { return <span>{i18n.t`Hello World`}</span> })

Now withI18n HOC is responsible not only for injecting i18n object, but also for forcing re-render when language or message catalog changes.

Other reason I might thing off: when you use i18n directly, you're using global variable, which makes component very hard for testing. I always use functions/variables passed as props instead of global ones.

What do you think? I'm really open for discussion here as there should be one and preferably only one way to do it.

okay, that sounds good. So the recommended approach for projects where both component and non-component code needs to be translated (all normal projects :D) is to
1 . call setupI18n to get the i18n object,
2 . pass it to i18nProvider and use this.props.i18n in components
3 . use the original i18n object outside of components

?

Yes!

In my project, I don't need i18n outside components. I'm working on React/Apollo app and everything is either a Component (React) or HOC (Apollo containers). AFAIK even redux-form has access to prop in validation function (my previous project) so I always considered using standalone i18n object as something special :)

okay, so let me rephrase that to "all normal react native projects" :)

I'll apply the suggested changes and push them this week. Where should I document the 1, 2, 3 steps?

Good point! I haven't worked with react-native yet.

I think this section is perfect place to document it. Later we might write a standalone guide to further explain differences and reasoning. For tutorial purposes, let's keep it simple.

One more question: we initially need to call setupI18n to get the i18n object. Later if I want to change the language, I could create a new i18n object by again calling setupI18n, or I can call i18n.load and i18n.activate like here. Which way should be documented? I kinda like the second one better but not sure if that api is stable..?

tricoder42 · 2018-07-16T21:00:09Z

docs/tutorials/react-native.rst


+The important point here is that the sentence isn't broken into pieces but remains together - that will allow the translator to deliver a quality result.


I love this! That's exactly the point.

tricoder42 · 2018-07-19T07:01:28Z

Definitely the second one. I’m not sure a new i18n would propagate cleanly to all places where is used. .load and .activate methods should be stable. They’re tested and also used by I18nProvider in React

…

On 19 Jul 2018, at 08:54, Vojtech Novak ***@***.***> wrote: @vonovak commented on this pull request. In docs/tutorials/react-native.rst: > + +.. code-block:: jsx + + import { setupI18n } from ***@***.***/core'; + + // this file is generated by the cli + import enMessages from './locale/en/messages.js'; + + let i18n = setupI18n({ + language: 'en', + catalogs: { + en: enMessages, + }, + }); + ... + <Button onPress={markAsRead} title={i18n.t`mark messages as read`} /> One more question: we initially need to call setupI18n to get the i18n object. Later if I want to change the language, I could create a new i18n object by again calling setupI18n, or I can call i18n.load and i18n.activate like here. Which way should be documented? I kinda like the second one better but not sure if that api is stable..? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

vonovak · 2018-07-20T07:25:24Z

I’m not sure a new i18n would propagate cleanly

yes, exactly.

So, the docs should be looking good now! I just need to update the example app and link it at the end of the tutorial.

vonovak · 2018-07-20T07:29:00Z

also, this probably closes #176

wip 2 add image fix typo use withI18n add demo link

codecov · 2018-07-21T08:18:26Z

Codecov Report

Merging #243 into stable-2.x will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           stable-2.x     #243   +/-   ##
===========================================
  Coverage       91.62%   91.62%           
===========================================
  Files              41       41           
  Lines             931      931           
===========================================
  Hits              853      853           
  Misses             78       78

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 85eb87a...a7580bb. Read the comment docs.

vonovak · 2018-07-21T08:28:04Z

@tricoder42 I rebased this onto stable-2.x so there are no conflicts, and updated the example app, so this is ready for another review (perhaps ready for merging :) ).

tricoder42 · 2018-07-22T13:32:05Z

This is nice! I'm gonna to merge it now. Thank you for you help! 🎉

tricoder42 reviewed Jul 12, 2018

View reviewed changes

vonovak changed the title ~~[wip] React native docs~~ React native docs Jul 13, 2018

tricoder42 reviewed Jul 16, 2018

View reviewed changes

wip

5c1bf1c

wip 2 add image fix typo use withI18n add demo link

vonovak added 2 commits July 21, 2018 10:21

remove unnecessary change

69d2fae

add contrib

a7580bb

tricoder42 added the 📖 documentation label Jul 22, 2018

tricoder42 merged commit f0ebd7d into lingui:stable-2.x Jul 22, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

React native docs #243

React native docs #243

vonovak commented Jul 11, 2018

tricoder42 left a comment

tricoder42 Jul 12, 2018

vonovak Jul 12, 2018 •

edited

Loading

vonovak commented Jul 13, 2018 •

edited

Loading

tricoder42 left a comment

tricoder42 Jul 16, 2018

vonovak Jul 16, 2018

tricoder42 Jul 16, 2018

vonovak Jul 16, 2018 •

edited

Loading

tricoder42 Jul 16, 2018

vonovak Jul 16, 2018

tricoder42 Jul 16, 2018

vonovak Jul 19, 2018

tricoder42 Jul 16, 2018

tricoder42 commented Jul 19, 2018 via email

vonovak commented Jul 20, 2018

vonovak commented Jul 20, 2018

codecov bot commented Jul 21, 2018 •

edited

Loading

vonovak commented Jul 21, 2018

tricoder42 commented Jul 22, 2018


		This was easy. Now, the next step is to translate the ``title`` prop of the ``Button`` component. But wait a sec, the button expects to receive a ``string``, so we cannot use the ``<Trans>`` component here! Also notice the same holds also for the ``Alert.alert`` call.

		At this point, we need to turn our attention to the ``@lingui/core`` package, namely the ``setupI18n`` method which can give us an object that we can use like this: ``i18n.t`this will be translated``` and the result of such call is a string. Let's get to it!


		The important point here is that the sentence isn't broken into pieces but remains together - that will allow the translator to deliver a quality result.

React native docs #243

React native docs #243

Conversation

vonovak commented Jul 11, 2018

tricoder42 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vonovak Jul 12, 2018 • edited Loading

Choose a reason for hiding this comment

vonovak commented Jul 13, 2018 • edited Loading

tricoder42 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vonovak Jul 16, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tricoder42 commented Jul 19, 2018 via email

vonovak commented Jul 20, 2018

vonovak commented Jul 20, 2018

codecov bot commented Jul 21, 2018 • edited Loading

Codecov Report

vonovak commented Jul 21, 2018

tricoder42 commented Jul 22, 2018

vonovak Jul 12, 2018 •

edited

Loading

vonovak commented Jul 13, 2018 •

edited

Loading

vonovak Jul 16, 2018 •

edited

Loading

codecov bot commented Jul 21, 2018 •

edited

Loading