Skip to content

A simple yet well-rounded React Native template for building large-scale applications.

Notifications You must be signed in to change notification settings

epshtielsl/rn-typescript-rtk-persistence-template

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

5 Commits
 
 
 
 
 
 
 
 

Repository files navigation

A better React Native Template

Built by QuintonC with 🖤

Want to help contribute? Feel free to open an issue.

🤙 Features

  • Built with modern development in mind.
  • Built with TypeScript.
  • Built with a focus on clean code.
  • Built with packages that are most commonly found in large, at-scale mobile applications.

🎁 Packages

This template makes use of some other packages.

🕺 Usage

First you should ensure that you have followed the setup instructions from the official React Native website.

You can view that here: Setting up the development environment

After you have your development environment setup, you then need to run the following to start your project:

npx react-native init ProjectName --template https://github.com/QuintonC/rn-typescript-rtk-persistence-template

Now that you have created your project you should be able to open the project folder itself and get to work. However, there is some explanation to do in terms of the file structure.

🏗 File Structure

You should mostly be paying attention to the files within the /src/ folder, as that is where most of your code will be written.

Inside of the /src/ directory we have a list of folders to go over.

src |
    | - @types // This is where your custom type definitions will go. I've already created one for your rootReducer (the combined reducer), which will help when destructuring within selectors.
    | - assets
        | - fonts // Custom fonts go here. I've included two, but you can scrap them and re-run npx react-native link to remove them from your project.
        | - icons // Any custom icons go here.
        | - images
        | - lottiefiles // While I didn't include lottie in this repo, it's something I use often, and I keep my lottie .json files here.
    | - components
        |- PackageCard // Each component should have its own folder. Within that folder an index.tsx and a style.tsx for the stylesheet of the component.
            | - index.tsx
            | - style.tsx
        | - index.tsx // A global index.tsx within the components folder. Each component is exported out of here. This helps maintain your clean import structure (more on this below).
    | - constants // Any app constants here.
    | - navigator // App navigation here.
    | - screens // Similar to components, however, I structure everything by stacks. So we could potentially have folders such as Auth, Home, Settings, etc. Each of those folders have their own screens within them.
        | - Home
            | - HomeRoot
                | - index.tsx
                | - style.tsx
        | - index.tsx // And similar to the components folder, we have an export within each stack's parent folder where we can import screens by stack.
    | - slices // Our redux slices go here.
    | - store // Our redux store configuration (combineReducers and configureStore) go here.
    | - style // Any app-wide styles you'd like to create for easier import and drier code. You'll notice I've defined some typography global styles.
    | - types // All of your types + interfaces, in one place.
        | - index.tsx
        | - typename.tsx
    | - utils // Any utility functions you need for your application.

🧼 Clean Imports

Why is there an index.tsx in components?

Within each index.tsx file within a parent folder, I export default exports from components, screens, etc. to help maintain cleaner imports when those components or screens are later used.

For example let's assume we have the following three components in our components folder.

  • Button
  • Input
  • PackageCard

Our components/index.tsx would look like this:

export { default as Button } from './Button';
export { default as Input } from './Input';
export { default as PackageCard } from './PackageCard';

Now, when we are using these components within a screen, we can import these three components like this:

// Components
import { Button, Input, PackageCard } from 'components';

Which, given there are only three components, isn't a huge deal compared to this:

// Components
import Button from 'components/Button';
import Input from 'components/Input';
import PackageCard from 'components/PackageCard';

However, as your app grows, it's most likely that the number of components follows suit. For example, let's assume you have 20 components nad you want to use them all in another screen. Do you really want to have 20+ lines of code dedicated to importing your components? Didn't think so.

🏎 VS Code Snippets

I've included two of my most commonly used VS Code snippets in this template. They should automatically pick up with your VS Code instance as well, ensuring that you can use them too.

When you create a new file such as a new index.tsx file, you can begin typing newcomponent, and VS Code will prompt you for a snippet replacement. What replaces that shortcut is:

import React, { useEffect, useRef, useState } from 'react';
import { Text, View } from 'react-native';

// Packages

// Components

// Style

// Assets

// Constants

// Types

// Actions

// Utility Functions

const ComponentName = () => {

 return (

 );

}
export default ComponentName;

Pretty sweet, right? Well, maybe you're just inside of a style or networking file and you don't necessarily need to create a component, instead, you can begin typing importstruct and VS Code will replace that shortcut is:

// Packages

// Components

// Style

// Assets

// Constants

// Types

// Actions

// Utility Functions

Now all of your files should be looking clean with a defined import structure. The rest is up to you 😄

✌️ Closing

Have any questions? Feel free to reach out to me on Twitter, or open an issue.

About

A simple yet well-rounded React Native template for building large-scale applications.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • TypeScript 47.3%
  • Java 20.7%
  • Objective-C 14.4%
  • JavaScript 12.6%
  • Ruby 3.1%
  • Starlark 1.9%