Quick Start

The Ignite boilerplate project's structure will look similar to this:

ignite-project
├── app
│   ├── components
│   ├── config
│   ├── i18n
│   ├── models
│   ├── navigators
│   ├── screens
│   ├── services
│   ├── theme
│   ├── utils
│   └── app.tsx
├── assets
│   ├── icons
│   └── images
├── test
│   ├── __snapshots__
│   ├── mockFile.ts
│   └── setup.ts
├── README.md
├── android
│   ├── app
│   ├── build.gradle
│   ├── gradle
│   ├── gradle.properties
│   ├── gradlew
│   ├── gradlew.bat
│   ├── keystores
│   └── settings.gradle
├── ignite
│   └── templates
|       |── app-icon
│       ├── component
│       ├── model
│       ├── navigator
│       └── screen
├── index.js
├── ios
│   ├── IgniteProject
│   ├── IgniteProject-tvOS
│   ├── IgniteProject-tvOSTests
│   ├── IgniteProject.xcodeproj
│   └── IgniteProjectTests
├── .env
└── package.json

./app directory

Included in an Ignite boilerplate project is the app directory. This is a directory you would normally have to create when using vanilla React Native.

The inside of the app directory looks similar to the following:

app
├── components
├── config
├── i18n
├── models
├── navigators
├── screens
├── services
├── theme
├── utils
└── app.tsx

components This is where your reusable components live which help you build your screens.

i18n This is where your translations will live if you are using react-native-i18n.

models This is where your app's models will live. Each model has a directory which will contain the mobx-state-tree model file, test file, and any other supporting files like actions, types, etc.

navigators This is where your react-navigation navigators will live.

screens This is where your screen components will live. A screen is a React component which will take up the entire screen and be part of the navigation hierarchy. Each screen will have a directory containing the .tsx file, along with any assets or other helper files.

services Any services that interface with the outside world will live here (think REST APIs, Push Notifications, etc.).

theme Here lives the theme for your application, including spacing, colors, and typography.

utils This is a great place to put miscellaneous helpers and utilities. Things like date helpers, formatters, etc. are often found here. However, it should only be used for things that are truly shared across your application. If a helper or utility is only used by a specific component or model, consider co-locating your helper with that component or model.

app.tsx This is the entry point to your app. This is where you will find the main App component which renders the rest of the application.

./assets directory

This directory is designed to organize and store various assets, making it easy for you to manage and use them in your application. The assets are further categorized into subdirectories, including icons and images:

assets
├── icons
└── images

icons This is where your icon assets will live. These icons can be used for buttons, navigation elements, or any other UI components. The recommended format for icons is PNG, but other formats can be used as well.

Ignite comes with a built-in Icon component. You can find detailed usage instructions in the docs.

images This is where your images will live, such as background images, logos, or any other graphics. You can use various formats such as PNG, JPEG, or GIF for your images.

Another valuable built-in component within Ignite is the AutoImage component. You can find detailed usage instructions in the docs.

How to use your icon or image assets:

import { Image } from 'react-native';

const MyComponent = () => {
  return (
    <Image source={require('../assets/images/my_image.png')} />
  );
};

./ignite directory

The ignite directory stores all things Ignite, including CLI and boilerplate items. Here you will find templates you can customize to help you get started with React Native.

./test directory

This directory will hold your Jest configs and mocks.

Running Maestro end-to-end tests

Follow our Maestro Setup recipe from the Ignite Cookbook!

Questions:

What does the single responsibility principle consist of? What's its purpose?

the principle is that each module or portion of the code should be dedicated exclusively to a responsibility

for example, if we have a Math module, it will only be dedicated to questions concerning mathematical problems, since this is its responsibility.

and it should not do anything else, for example to do json parsing.

What characteristics does, in your opinion, a “good” code or clean code have?

For me a good code is one that is simple to understand.

a code that is written to be read by a human being in a quick way.

a code that is abstract enough (in a good way), to be able to know what it does without having to see the detail.

then this detail should be easily accessible if necessary, but it should not be

Detail how you would do everything that you have not completed.

Write tests for everything primarily for the most important parts of the app, aiming in this case for 100% coverage.

do the testing of the request handlers (using mocks)

then write e2e tests for all flows.

this will go a long way to see that all flows work and display correctly on a wide range of devices without having to do manual testing.