React Native Tutorial

[alexeuler]

This change is 

[robwise]

Love that you figured out the Jest stuff! I feel like that's a much better solution for component testing than Enzyme

---

Reviewed 114 of 114 files at r1.
Review status: all files reviewed at latest revision, 28 unresolved discussions, some commit checks broke.

---

mobile/ReactNativeTutorial/.babelrc, line 2 at r1 (raw file):

{
"presets": ["react-native"]

indent two

---

mobile/ReactNativeTutorial/.babelrc, line 3 at r1 (raw file):

{
"presets": ["react-native"]
}

missing eof line return

---

mobile/ReactNativeTutorial/.eslintignore, line 1 at r1 (raw file):

node_modules

this is already ignored

---

mobile/ReactNativeTutorial/.eslintignore, line 4 at r1 (raw file):

ios
android
.git

Is it necessary to ignore .git? I've never had any issues with that

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 3 at r1 (raw file):

---
  extends:
    - "eslint-config-shakacode"

@justin808 I would recommend also using:

  - plugin:lodash-fp/recommended
  - plugin:flowtype/recommended

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 27 at r1 (raw file):

    ReactClass: true
    ReactElement: true
    fetch: true

these last 3 shouldn't be necessary?

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 29 at r1 (raw file):

    fetch: true
  rules:
    new-cap: 0

why this one?

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 30 at r1 (raw file):

  rules:
    new-cap: 0
    react/sort-comp: 0

I don't think we should disable this

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 31 at r1 (raw file):

    new-cap: 0
    react/sort-comp: 0
    no-console: 0

I don't think we should disable this

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 32 at r1 (raw file):

    react/sort-comp: 0
    no-console: 0
    import/imports-first: 2

this is already on

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 33 at r1 (raw file):

    no-console: 0
    import/imports-first: 2
    import/prefer-default-export: 2

this is already on

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 34 at r1 (raw file):

    import/imports-first: 2
    import/prefer-default-export: 2
    no-duplicate-imports: 0

this should be fixed now so we can remove

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 39 at r1 (raw file):

    # Delegating proptypes check to flow
    react/prop-types: 0

This shouldn't be necessary since you're using the flowtype plugin

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 51 at r1 (raw file):

      - extensions: [".js", ".jsx"]

    flowtype/require-parameter-type: 1

I think for these flow ones we should just go with plugin:flowtype/recommended, that way we can just keep that plugin up to date and not have to put thought into manually keeping our rules in sync with the latest flow guidelines

---

mobile/ReactNativeTutorial/.flowconfig, line 67 at r1 (raw file):

[version]
^0.33.0

might as well bump this since this implementation is greenfield

---

mobile/ReactNativeTutorial/.watchmanconfig, line 1 at r1 (raw file):

{}

missing eof line return

---

mobile/ReactNativeTutorial/app/api/index.js, line 36 at r1 (raw file):

export const postComment = async (payload) => {
  const response = await postRequest('comments.json', { comment: payload });
  const camelizedResponse = _.mapKeys(_.camelCase, response);

If there aren't edge cases, perhaps we should do this at the end of apiRequest's implementation?

---

mobile/ReactNativeTutorial/app/api/index.js, line 37 at r1 (raw file):

  const response = await postRequest('comments.json', { comment: payload });
  const camelizedResponse = _.mapKeys(_.camelCase, response);
  const commentSchema = new Schema('comments');

I would put all schema definitions in one, separate file, and then import them here. Otherwise, you're going to have duped schema definitions all over the app. Right now it's not that bad because comments doesn't have any associated entities, but that's not always the case.

---

mobile/ReactNativeTutorial/app/bundles/comments/components/Index/Footer/Footer.js, line 16 at r1 (raw file):

      name="add"
      color="#f50"
      onPress={() => Actions.commentsAdd()}

Here I would just drop the fat arrow and pass the function without invoking it. This prevents extra functions from being created every time you re-render the footer, which is okay if you really need to do it, but you don't here because you aren't passing any args

---

mobile/ReactNativeTutorial/app/bundles/comments/components/Index/List/List.js, line 17 at r1 (raw file):

    _.sortBy(_.get('id')),
    _.values
  )(props.comments);

This type of thing should be in the selector to prevent unnecessary re-computations of the sort when other unrelated props cause this component to re-render

---

mobile/ReactNativeTutorial/app/bundles/comments/hocs/withIndexProps.js, line 30 at r1 (raw file):

  commentsPropsSelector,
  props => props.toJS()
);

Why not keep this selector in the selectors folder?

---

mobile/ReactNativeTutorial/app/reducers/commentsStoreReducer.js, line 5 at r1 (raw file):

const CREATE = 'COMMENTS_STORE:CREATE';
const REMOVE = 'COMMENTS_STORE:REMOVE';
const SET_LOADING = 'COMMENTS_STORE:SET_LOADING';

I don't think we should be putting actions inside of reducer files. Actions are not meant to have a 1-to-1 relationship with reducers like this (it defeats a lot of the usefulness of Redux). See pitzcarraldo/reduxible#8

---

mobile/ReactNativeTutorial/app/reducers/commentsStoreReducer.js, line 9 at r1 (raw file):

export const initialState = fromJS({
  meta: {
    loading: false,

I wouldn't keep app state next to entities state as a general rule. I would put into two separate reducers comments which is a $$Map of comments and isLoadingComments which is just a boolean. Fedoseev and I are both moving towards that style where we have an entities domain where we keep all relational, server-provided data, and then a separate area where we keep app state.

---

mobile/ReactNativeTutorial/app/reducers/commentsStoreReducer.js, line 17 at r1 (raw file):

const setLoading = (state, action) => state.setIn(['meta', 'loading'], action.loading);

export default (state, action) => {

I think the convention is export default (state = initialState, action) => { which would save you four lines

---

mobile/ReactNativeTutorial/app/setup/loggerMiddleware.js, line 3 at r1 (raw file):

import _ from 'lodash/fp';

export default function logger({ getState }) {

Are you sure you don't want to just use redux-logger? It can handle Immutable if you do it like this:

import createLogger from 'redux-logger';
import _ from 'lodash/fp';

const stateTransformer = _.mapValues(store => (store.toJS ? store.toJS() : store));
const loggerMiddleware = createLogger({ stateTransformer });

---

mobile/ReactNativeTutorial/app/setup/store.js, line 12 at r1 (raw file):
this is the old syntax, I think the new syntax is a little easier to read:

const middlewares = __DEV__ ? [effectsMiddleware, loggerMiddleware] : [effectsMiddleware];

export default createStore(appReducer, initialState, applyMiddleware(...middlewares));

Also, you usually want your logging to go last because most people don't want to log promises or thunks, although I noticed you do that with your custom logger:

Logger must be the last middleware in chain, otherwise it will log thunk and promise

source

---

mobile/ReactNativeTutorial/app/setup/Router/Router.js, line 9 at r1 (raw file):

const reducerCreate = params => {
  const defaultReducer = Reducer(params);

this const doesn't seem necessary, I would just inline it

---

mobile/ReactNativeTutorial/app/utils/redux.js, line 4 at r1 (raw file):

import _ from 'lodash/fp';

export const getNewId = (store) => {

Somewhat abstract lib utils like this can sometimes really do with a good comment, especially if this is to be used as a tutorial

---

Comments from Reviewable

[justin808]

Reviewed 108 of 114 files at r1, 11 of 11 files at r2.
Review status: all files reviewed at latest revision, 28 unresolved discussions, some commit checks broke.

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 3 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

@justin808 I would recommend also using:

  - plugin:lodash-fp/recommended
  - plugin:flowtype/recommended

Agree with Rob!

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 30 at r1 (raw file):

react/sort-comp:
agree

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 31 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

I don't think we should disable this

agreee

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 51 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

I think for these flow ones we should just go with plugin:flowtype/recommended, that way we can just keep that plugin up to date and not have to put thought into manually keeping our rules in sync with the latest flow guidelines

agree

---

mobile/ReactNativeTutorial/app/api/index.js, line 36 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

If there aren't edge cases, perhaps we should do this at the end of apiRequest's implementation?

This is only one level deep. I guess it's OK for a specialized case.

---

mobile/ReactNativeTutorial/app/api/index.js, line 37 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

I would put all schema definitions in one, separate file, and then import them here. Otherwise, you're going to have duped schema definitions all over the app. Right now it's not that bad because comments doesn't have any associated entities, but that's not always the case.

Might be worth a try. We need to balance out simplicity vs. realism.

---

Comments from Reviewable

[justin808]

Review status: all files reviewed at latest revision, 29 unresolved discussions, some commit checks broke.

---

mobile/ReactNativeTutorial/app/bundles/comments/components/Index/Footer/Footer.js, line 16 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

Here I would just drop the fat arrow and pass the function without invoking it. This prevents extra functions from being created every time you re-render the footer, which is okay if you really need to do it, but you don't here because you aren't passing any args

nice one

---

mobile/ReactNativeTutorial/app/bundles/comments/components/Index/List/List.js, line 13 at r2 (raw file):

const List = (props: PropsType) => {
  const data = _.compose(

why compose and not flowRight? Yes, an alias, but now you have to know all 60 of these: https://github.com/lodash/lodash/wiki/FP-Guide#aliasesJ

---

mobile/ReactNativeTutorial/app/reducers/commentsStoreReducer.js, line 5 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

I don't think we should be putting actions inside of reducer files. Actions are not meant to have a 1-to-1 relationship with reducers like this (it defeats a lot of the usefulness of Redux). See pitzcarraldo/reduxible#8

I think this is a redux ducks pattern here

---

mobile/ReactNativeTutorial/app/utils/redux.js, line 4 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

Somewhat abstract lib utils like this can sometimes really do with a good comment, especially if this is to be used as a tutorial

I agree with Rob. Yes, this file gets a new id.

---

Comments from Reviewable

[robwise]

Review status: all files reviewed at latest revision, 29 unresolved discussions, some commit checks broke.

---

mobile/ReactNativeTutorial/app/bundles/comments/components/Index/List/List.js, line 13 at r2 (raw file):

Previously, justin808 (Justin Gordon) wrote…

why compose and not flowRight? Yes, an alias, but now you have to know all 60 of these: https://github.com/lodash/lodash/wiki/FP-Guide#aliasesJ

most FP languages call this compose (as well as ramda as well as Redux's version), so even though it's listed as an alias in lodash/fp, it's actually the name you'll more commonly see, for what that's worth

---

mobile/ReactNativeTutorial/app/reducers/commentsStoreReducer.js, line 5 at r1 (raw file):

Previously, justin808 (Justin Gordon) wrote…

I think this is a redux ducks pattern here

Yeah, I should say that there are people who do it this way, we (Alexey, Alex, and I) just had a talk about this and how we should be tolerant of other people's styles. If you do it this way, then you would tend to dispatch multiple actions in your thunk if you needed to change multiple reducers, making your actions more like setters. I and Abramov and Alex have some qualms with that, but at the end of the day both work. It's this point that really sets apart redux stories from redux ducks.

---

Comments from Reviewable

[alex35mil]

Lots of icon fonts btw, any reason to prefer them over svg w/ React Native or it's just for simplicity sake?

---

Reviewed 108 of 114 files at r1, 11 of 11 files at r2.
Review status: all files reviewed at latest revision, 34 unresolved discussions, some commit checks broke.

---

mobile/ReactNativeTutorial/android/gradlew, line 164 at r2 (raw file):

JVM_OPTS[${#JVM_OPTS[*]}]="-Dorg.gradle.appname=$APP_BASE_NAME"

exec "$JAVACMD" "${JVM_OPTS[@]}" -classpath "$CLASSPATH" org.gradle.wrapper.GradleWrapperMain "$@"

airy! ✨

---

mobile/ReactNativeTutorial/app/bundles/comments/components/Index/List/ListStyle.js, line 5 at r2 (raw file):

const styles = StyleSheet.create({
  container: {
  },

Nothing here, is this intentional?

---

mobile/ReactNativeTutorial/app/reducers/commentFormReducer.js, line 32 at r2 (raw file):

  updateCommentForm,
  resetCommentForm,
};

Why this file is not typed?

---

mobile/ReactNativeTutorial/app/reducers/commentsStoreReducer.js, line 5 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

Yeah, I should say that there are people who do it this way, we (Alexey, Alex, and I) just had a talk about this and how we should be tolerant of other people's styles. If you do it this way, then you would tend to dispatch multiple actions in your thunk if you needed to change multiple reducers, making your actions more like setters. I and Abramov and Alex have some qualms with that, but at the end of the day both work. It's this point that really sets apart redux stories from redux ducks.

Right, I prefer pattern one action -> multiple reducers reaction instead of dispatching multiple actions b/c batched updates reduce amount of store updates (-> components re-renders) + I don't need to think about the cases when temporary invalid state can crash components tree on re-render.

---

mobile/ReactNativeTutorial/app/reducers/commentsStoreReducer.js, line 9 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

I wouldn't keep app state next to entities state as a general rule. I would put into two separate reducers comments which is a $$Map of comments and isLoadingComments which is just a boolean. Fedoseev and I are both moving towards that style where we have an entities domain where we keep all relational, server-provided data, and then a separate area where we keep app state.

Agreed on this separation in big apps. I treat entities as client's data base and store only data, that was persisted on the server. It's a source of truth (data) for many components and it's decoupled from UI "global" part of the state. View layer related state I hold in separate reducers (usually next to the UI components as most of the time this state is "local" (in terms of usage) and coupled to the single part of UI).

---

mobile/ReactNativeTutorial/app/selectors/commentsPropsSelector.js, line 8 at r2 (raw file):

  commentsStoreSelector,
  commentsStore => Map({
    comments: commentsStore.delete('meta').valueSeq().sort((a, b) => b.get('id') - a.get('id')),

sortBy might be more appropriate here.

---

mobile/ReactNativeTutorial/app/setup/loggerMiddleware.js, line 3 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

Are you sure you don't want to just use redux-logger? It can handle Immutable if you do it like this:

import createLogger from 'redux-logger';
import _ from 'lodash/fp';

const stateTransformer = _.mapValues(store => (store.toJS ? store.toJS() : store));
const loggerMiddleware = createLogger({ stateTransformer });

BTW I noticed that it has issue w/ reducers, which state is not an object: https://cl.ly/iIPo (it treats them as an empty objects).
In general I prefer dev tools, b/c it's invisible and doesn't pollute console that much.

---

mobile/ReactNativeTutorial/ios/ReactNativeTutorial.xcodeproj/project.pbxproj, line 7 at r2 (raw file):

	};
	objectVersion = 46;
	objects = {

Let's use spaces! 🤓 😅

---

Comments from Reviewable

[alexeuler]

@alexfedoseev They use it in the standard libs for RN, probably that's because mobile is optimized for fonts rather than svgs I've rarely seen any svgs there.

---

Review status: 99 of 119 files reviewed at latest revision, 35 unresolved discussions, some commit checks failed.

---

mobile/ReactNativeTutorial/.babelrc, line 2 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

indent two

Done.

---

mobile/ReactNativeTutorial/.babelrc, line 3 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

missing eof line return

Done.

---

mobile/ReactNativeTutorial/.eslintignore, line 1 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

this is already ignored

Done.

---

mobile/ReactNativeTutorial/.eslintignore, line 4 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

Is it necessary to ignore .git? I've never had any issues with that

Done.

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 3 at r1 (raw file):

Previously, justin808 (Justin Gordon) wrote…

Agree with Rob!

Done.

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 27 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

these last 3 shouldn't be necessary?

Removed React*, fetch is necessary as it's a global function in RN

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 29 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

why this one?

I abandoned here the notation of $$Map for immutable and use just Map, for that I need to ignore this.

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 30 at r1 (raw file):

Previously, justin808 (Justin Gordon) wrote…

react/sort-comp:
agree

Done.

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 31 at r1 (raw file):

Previously, justin808 (Justin Gordon) wrote…

agreee

Done.

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 32 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

this is already on

Done.

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 33 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

this is already on

Done.

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 34 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

this should be fixed now so we can remove

Done.

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 39 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

This shouldn't be necessary since you're using the flowtype plugin

Done.

---

mobile/ReactNativeTutorial/.eslintrc.yml, line 51 at r1 (raw file):

Previously, justin808 (Justin Gordon) wrote…

agree

Done.

---

mobile/ReactNativeTutorial/.flowconfig, line 67 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

might as well bump this since this implementation is greenfield

I guess I'll leave it, as this is a standard React Native template, coming from the generator

---

mobile/ReactNativeTutorial/.watchmanconfig, line 1 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

missing eof line return

Done.

---

mobile/ReactNativeTutorial/app/api/index.js, line 37 at r1 (raw file):

Previously, justin808 (Justin Gordon) wrote…

Might be worth a try. We need to balance out simplicity vs. realism.

Done.

---

mobile/ReactNativeTutorial/app/bundles/comments/components/Index/Footer/Footer.js, line 16 at r1 (raw file):

Previously, justin808 (Justin Gordon) wrote…

nice one

Done.

---

mobile/ReactNativeTutorial/app/bundles/comments/components/Index/List/List.js, line 17 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

This type of thing should be in the selector to prevent unnecessary re-computations of the sort when other unrelated props cause this component to re-render

@robwise That's a nice one, I actually moved the sorting code to selectors long time ago, but forgot to delete this code lol )

---

mobile/ReactNativeTutorial/app/bundles/comments/components/Index/List/List.js, line 13 at r2 (raw file):

Previously, robwise (Rob Wise) wrote…

most FP languages call this compose (as well as ramda as well as Redux's version), so even though it's listed as an alias in lodash/fp, it's actually the name you'll more commonly see, for what that's worth

Yeah, precisely for the reason Rob stated above.

---

mobile/ReactNativeTutorial/app/bundles/comments/hocs/withIndexProps.js, line 30 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

Why not keep this selector in the selectors folder?

I try to keep selectors uniform in terms of using only immutable. That way you can simply reuse any selector for new selector not keeping in mind whether it is JS or immutable. Once you leave selectors realm and try to connect component you convert Immutable to JS

---

mobile/ReactNativeTutorial/app/reducers/commentFormReducer.js, line 32 at r2 (raw file):

Previously, alexfedoseev (Alex Fedoseev) wrote…

Why this file is not typed?

Basically because nothing to typecheck here, all states are immutable maps, all actions are hashmaps, and each reducer either returns initialState or merges smth

---

mobile/ReactNativeTutorial/app/reducers/commentsStoreReducer.js, line 5 at r1 (raw file):

Previously, alexfedoseev (Alex Fedoseev) wrote…

Right, I prefer pattern one action -> multiple reducers reaction instead of dispatching multiple actions b/c batched updates reduce amount of store updates (-> components re-renders) + I don't need to think about the cases when temporary invalid state can crash components tree on re-render.

Well in Spylight I found this approach really messy. That's because we got heavy reuse of components and reducers and the latter grew really big and clumsy. Here I use two types of actions ones are simple redux actions close to redux state structure, others are thunks close to UI structure, built on top of basic actions. I also think that this approach is in line with what we're used to in MVC approach, where redux state is model and UI are controllers - you don't put the code inside model that reacts to different controllers, you do it the other way round - controllers use model's code.

---

mobile/ReactNativeTutorial/app/reducers/commentsStoreReducer.js, line 9 at r1 (raw file):

Previously, alexfedoseev (Alex Fedoseev) wrote…

Agreed on this separation in big apps. I treat entities as client's data base and store only data, that was persisted on the server. It's a source of truth (data) for many components and it's decoupled from UI "global" part of the state. View layer related state I hold in separate reducers (usually next to the UI components as most of the time this state is "local" (in terms of usage) and coupled to the single part of UI).

I agree on storing view state inside separate reducer, but here I use meta as the state of the entities state, not the part of UI. I didn't fully understand how do you propose to structure this, smth like this?

{
  meta: {
    comments: {
      ...
    },
    people: {
      ...
    }
  },

  comments: {
     1: {...}
  },
  people: {
     1: {...}
  },
}

@robwise @alexfedoseev

---

mobile/ReactNativeTutorial/app/reducers/commentsStoreReducer.js, line 17 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

I think the convention is export default (state = initialState, action) => { which would save you four lines

Done.

---

mobile/ReactNativeTutorial/app/selectors/commentsPropsSelector.js, line 8 at r2 (raw file):

Previously, alexfedoseev (Alex Fedoseev) wrote…

sortBy might be more appropriate here.

Done.

---

mobile/ReactNativeTutorial/app/setup/loggerMiddleware.js, line 3 at r1 (raw file):

Previously, alexfedoseev (Alex Fedoseev) wrote…

BTW I noticed that it has issue w/ reducers, which state is not an object: https://cl.ly/iIPo (it treats them as an empty objects).
In general I prefer dev tools, b/c it's invisible and doesn't pollute console that much.

I'm doing some advanced logging here and DevTools is just for web.

---

mobile/ReactNativeTutorial/app/setup/store.js, line 12 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

this is the old syntax, I think the new syntax is a little easier to read:

const middlewares = __DEV__ ? [effectsMiddleware, loggerMiddleware] : [effectsMiddleware];

export default createStore(appReducer, initialState, applyMiddleware(...middlewares));

Also, you usually want your logging to go last because most people don't want to log promises or thunks, although I noticed you do that with your custom logger:

Logger must be the last middleware in chain, otherwise it will log thunk and promise

source

Done.

---

mobile/ReactNativeTutorial/app/setup/Router/Router.js, line 9 at r1 (raw file):

Previously, robwise (Rob Wise) wrote…

this const doesn't seem necessary, I would just inline it

Done.

---

mobile/ReactNativeTutorial/app/utils/redux.js, line 4 at r1 (raw file):

Previously, justin808 (Justin Gordon) wrote…

I agree with Rob. Yes, this file gets a new id.

Done.

---

mobile/ReactNativeTutorial/ios/ReactNativeTutorial.xcodeproj/project.pbxproj, line 7 at r2 (raw file):

Previously, alexfedoseev (Alex Fedoseev) wrote…

Let's use spaces! 🤓 😅

Nah - tabs!!!! ))))

---

mobile/ReactNativeTutorial/app/bundles/comments/components/Index/List/ListStyle.js, line 5 at r2 (raw file):

Previously, alexfedoseev (Alex Fedoseev) wrote…

Nothing here, is this intentional?

Usually I left this empty intentional, because this is very frequent way of styling, but I guess I'll drop it in the tutorial

---

Comments from Reviewable

[justin808]

I left a few comments.

@robwise @alexfedoseev @alleycat-at-git Nicer that we can use basic redux-thunk.

Should the mocks go into a separate repo?

---

Reviewed 32 of 34 files at r3.
Review status: 120 of 122 files reviewed at latest revision, 37 unresolved discussions.

---

mobile/ReactNativeTutorial/Readme.md, line 11 at r3 (raw file):

brew install node

I recommend nvm and installing latest stable.

---

mobile/ReactNativeTutorial/Readme.md, line 31 at r3 (raw file):

* The url can be changed app/api/index.js. Keep in mind, that Android emulator is in essence, 
a separate Virtual Machine with its own localhost binding. To make the api available under emulator,
you have to use ip address of your computer, that could be seen by running `ifconfig` in the shell

remove words "in essence"

---

mobile/ReactNativeTutorial/mocks/mockCall.js, line 24 at r3 (raw file):

export const resetMockCalls = () => mockCall.reset();

const call = ({ dispatch }) => (f, ...args) => {

A little bit of documentation here could go a long way.

---

Comments from Reviewable

[alexeuler]

Review status: 120 of 122 files reviewed at latest revision, 37 unresolved discussions.

---

mobile/ReactNativeTutorial/Readme.md, line 11 at r3 (raw file):

Previously, justin808 (Justin Gordon) wrote…

I recommend nvm and installing latest stable.

Done.

---

mobile/ReactNativeTutorial/Readme.md, line 31 at r3 (raw file):

Previously, justin808 (Justin Gordon) wrote…

remove words "in essence"

Done.

---

mobile/ReactNativeTutorial/mocks/mockCall.js, line 24 at r3 (raw file):

Previously, justin808 (Justin Gordon) wrote…

A little bit of documentation here could go a long way.

Done.

---

Comments from Reviewable

[justin808]

Reviewed 2 of 34 files at r3, 2 of 7 files at r4.
Review status: 122 of 127 files reviewed at latest revision, 38 unresolved discussions.

---

mobile/ReactNativeTutorial/docs/Introduction.md, line 24 at r4 (raw file):

React native is a pure UI rendering framework. To add business logic to the app we use Redux
framework, which handles the job of updating application state and providing data to the UI.
The overall scheme of the app is provided below:

React native is a pure UI rendering framework. To add business logic to the app, we use the Redux
framework, which handles the job of updating application state and providing data to the UI.
The overall scheme of the app is provided below.

---

mobile/ReactNativeTutorial/docs/Introduction.md, line 28 at r4 (raw file):

![Scheme](images/scheme.png)

The app therefore is functioning in the circular way: 

in the following way

---

mobile/ReactNativeTutorial/docs/Introduction.md, line 58 at r4 (raw file):

- Containers
- UI components
- Thunks

we should just merge this

---

Comments from Reviewable