diff --git a/404.html b/404.html index 2afd9e1e..32b7d262 100644 --- a/404.html +++ b/404.html @@ -10,8 +10,8 @@ - - + +
Skip to main content

Authentication with Supabase

Overview​

+

Authentication with Supabase

Overview​

Many applications require an external service to authenticate the user. Setting up authentication for your application can feel daunting. Where do I start? What data do I need from my users? What service(s) should or could I use? What are the signup, signin, and other user flows that I'll need?

This recipe is going to use Supabase as the backend. We'll build some primitives that will allow you to customize the authentication to your needs or existing backend service as well.

Requirements​

diff --git a/docs/recipes/CircleCIRNSetup/index.html b/docs/recipes/CircleCIRNSetup/index.html index d16199a7..41b5b7f3 100644 --- a/docs/recipes/CircleCIRNSetup/index.html +++ b/docs/recipes/CircleCIRNSetup/index.html @@ -10,8 +10,8 @@ - - + +

CircleCI CD Setup - React Native

This document shows the steps necessary to set up CircleCI automatic continuous integration testing and automatic Fastlane beta builds upon successfully merging a pull request.

+

CircleCI CD Setup - React Native

This document shows the steps necessary to set up CircleCI automatic continuous integration testing and automatic Fastlane beta builds upon successfully merging a pull request.

First Things First​

  1. Write Tests
    2. diff --git a/docs/recipes/CreatingGreateExperienceForScreenReaders/index.html b/docs/recipes/CreatingGreateExperienceForScreenReaders/index.html index c5de884c..c5dbfeef 100644 --- a/docs/recipes/CreatingGreateExperienceForScreenReaders/index.html +++ b/docs/recipes/CreatingGreateExperienceForScreenReaders/index.html @@ -10,8 +10,8 @@ - - + +

    Creating a Good Experience for Screen Readers

    UI Patterns​

    +

    Creating a Good Experience for Screen Readers

    UI Patterns​

    Screens​

    Titles All screen should ideally have unique titles, to make it easier to know quickly which screen you're on source.

    diff --git a/docs/recipes/DetoxIntro/index.html b/docs/recipes/DetoxIntro/index.html index b885883d..6b27ccca 100644 --- a/docs/recipes/DetoxIntro/index.html +++ b/docs/recipes/DetoxIntro/index.html @@ -10,8 +10,8 @@ - - + +

    Detox Intro

    Detox is a library for end-to-end testing of React Native apps. This wiki provides information on how to use Detox effectively.

    +

    Detox Intro

    Detox is a library for end-to-end testing of React Native apps. This wiki provides information on how to use Detox effectively.

    Installation​

    Detox's documentation for installation.

    What's unique about Detox​

    diff --git a/docs/recipes/DistributingAuthTokenToAPI/index.html b/docs/recipes/DistributingAuthTokenToAPI/index.html index 65f4c9bf..6adaee02 100644 --- a/docs/recipes/DistributingAuthTokenToAPI/index.html +++ b/docs/recipes/DistributingAuthTokenToAPI/index.html @@ -10,8 +10,8 @@ - - + +

    Distributing Auth Token to APISauce

    +

    Distributing Auth Token to APISauce

    Building off of the Ignite Boilerplate, this recipe will show you how to connect your Mobx State Tree Authentication Store with an Apisauce instance to make authenticating your API requests a breeze.

    Review of API Instance and Auth Store​

    To start off let's quickly review the boilerplate Auth Store and API Instance.

    diff --git a/docs/recipes/EASUpdate/index.html b/docs/recipes/EASUpdate/index.html index d2d60d6a..89afd032 100644 --- a/docs/recipes/EASUpdate/index.html +++ b/docs/recipes/EASUpdate/index.html @@ -10,8 +10,8 @@ - - + +

    EAS Update

    +

    EAS Update

    This guide will teach you how to set up over-the-air (OTA) updates with Expo and EAS Update within an Ignite project.

    Appetizer​

    You'll also need eas-cli globally installed and and an Expo account if you don't already have one.

    diff --git a/docs/recipes/EnforcingImportOrder/index.html b/docs/recipes/EnforcingImportOrder/index.html index 47554168..795a465b 100644 --- a/docs/recipes/EnforcingImportOrder/index.html +++ b/docs/recipes/EnforcingImportOrder/index.html @@ -10,8 +10,8 @@ - - + +

    Enforcing JS/TS Import Order

    +

    Enforcing JS/TS Import Order

    Overview​

    With Intellisense and Copilot at our fingertips, it's easy to forget that the order of imports in a file can have a big impact on the readability and maintainability of your code. Import helpers typically just put the autogenerated import at the bottom of all the other imports.

    This recipe will show you how to enforce a consistent import order in your project using the @serverless-guru/prettier-plugin-import-order prettier plugin.

    diff --git a/docs/recipes/EnvironmentVariables/index.html b/docs/recipes/EnvironmentVariables/index.html index b049c106..f419b8fd 100644 --- a/docs/recipes/EnvironmentVariables/index.html +++ b/docs/recipes/EnvironmentVariables/index.html @@ -10,8 +10,8 @@ - - + +

    Environment Variables

    +

    Environment Variables

    Setup​

    Install​

    yarn add -D dotenv babel-plugin-inline-dotenv
    diff --git a/docs/recipes/ExpoRouter/index.html b/docs/recipes/ExpoRouter/index.html index 5b7512d3..108fa289 100644 --- a/docs/recipes/ExpoRouter/index.html +++ b/docs/recipes/ExpoRouter/index.html @@ -10,8 +10,8 @@ - - + +

    Expo Router

    +

    Expo Router

    Overview​

    Expo Router brings file-based routing to React Native and web applications allowing you to easily create universal apps. Whenever a file is added to your src/app directory, a new path is automatically added to your navigation.

    For the full documentation by Expo, head on over to the Introduction to Expo Router.

    diff --git a/docs/recipes/GeneratorComponentTests/index.html b/docs/recipes/GeneratorComponentTests/index.html index 1d81b5ff..f270b46a 100644 --- a/docs/recipes/GeneratorComponentTests/index.html +++ b/docs/recipes/GeneratorComponentTests/index.html @@ -10,8 +10,8 @@ - - + +

    Add component tests to npx ignite-cli generate component

    +

    Add component tests to npx ignite-cli generate component

    Did you know that Ignite automatically generates files for you? And that you can customize those generators?

    Here is how to automatically generate components and tests for them using @testing-library/react-native

    Setup @testing-library/react-native​

    diff --git a/docs/recipes/LocalFirstDataWithPowerSync/index.html b/docs/recipes/LocalFirstDataWithPowerSync/index.html index d2076b80..6ef8c14f 100644 --- a/docs/recipes/LocalFirstDataWithPowerSync/index.html +++ b/docs/recipes/LocalFirstDataWithPowerSync/index.html @@ -10,8 +10,8 @@ - - + +

    PowerSync and Supabase for Local-First Data Management

    +

    PowerSync and Supabase for Local-First Data Management

    Introduction​

    This guide helps you integrate PowerSync with Supabase in an Ignite app for efficient local-first data management.

    PowerSync allows your app to work smoothly offline while keeping the data in sync with your backend database.

    diff --git a/docs/recipes/MaestroSetup/index.html b/docs/recipes/MaestroSetup/index.html index 7ec2ff3d..83d9ffac 100644 --- a/docs/recipes/MaestroSetup/index.html +++ b/docs/recipes/MaestroSetup/index.html @@ -10,8 +10,8 @@ - - + +

    Setting Up Maestro in Ignite

    +

    Setting Up Maestro in Ignite

    Overview​

    End-to-end (e2e) testing is a critical part of any application but it can be difficult to set up and maintain. Maestro is a tool that promises to be easy to set up and maintain e2e tests. This recipe will walk you through setting up Maestro in your Ignite project.

    Maestro Installation​

    diff --git a/docs/recipes/MigratingToI18Next/index.html b/docs/recipes/MigratingToI18Next/index.html index d44b7dcf..55adab4d 100644 --- a/docs/recipes/MigratingToI18Next/index.html +++ b/docs/recipes/MigratingToI18Next/index.html @@ -10,8 +10,8 @@ - - + +

    Migrating from i18n-js to react-i18next within an Ignite project

    +

    Migrating from i18n-js to react-i18next within an Ignite project

    Overview​

    In this guide, we will be going through the steps required to migrate your Ignite generated project from using i18n-js to the react-i18next library. It is meant specifically for projects generated with version 9 and below.

    react-i18next will be included in Ignite's version 10. If you're using an earlier version, this guide provides the necessary steps to successfully complete the migration.

    diff --git a/docs/recipes/MigratingToMMKV/index.html b/docs/recipes/MigratingToMMKV/index.html index e99eed62..c3ffc8f0 100644 --- a/docs/recipes/MigratingToMMKV/index.html +++ b/docs/recipes/MigratingToMMKV/index.html @@ -10,8 +10,8 @@ - - + +

    Migrating to MMKV

    +

    Migrating to MMKV

    Overview​

    MMKV is said to be the fastest key/value storage for React Native. It has encryption support for secure local storage and also uses synchronous storage to simplify your application code.

    In this recipe, we'll convert our the Ignite demo project from using AsyncStorage to MMKV.

    @@ -60,6 +60,6 @@

    Code Chan
  2. Tap on the "Podcast"

Now let's swipe the app away to close it. Re-open the app to see if the navigation picks up where we left off (which shows our storage is working to remember the navigation key we were last on).

-

And that's it! Ignite is now configured with react-native-mmkv over AsyncStorage.

Is this page still up to date? Did it work for you?

+

And that's it! Ignite is now configured with react-native-mmkv over AsyncStorage.

Is this page still up to date? Did it work for you?

\ No newline at end of file diff --git a/docs/recipes/MonoreposOverview/index.html b/docs/recipes/MonoreposOverview/index.html new file mode 100644 index 00000000..b0f78a2b --- /dev/null +++ b/docs/recipes/MonoreposOverview/index.html @@ -0,0 +1,134 @@ + + + + + +Choosing the right monorepo strategy for your project | Ignite Cookbook for React Native + + + + + + + + + + +

Choosing the right monorepo strategy for your project

+

Introduction​

+

When embarking on a software development project, particularly in the context of React Native and using the Ignite framework, the decision to adopt a monorepo structure is critical. A monorepo can streamline development, foster better code sharing, and simplify dependency management. However, it's not a one-size-fits-all solution. This document explores when you should consider using a monorepo, when you might want to avoid it, the most common monorepo options available, and typical setups for software applications.

+

When to use a monorepo​

+
    +
  • +

    Code sharing across multiple projects: If your project involves multiple apps or services that share a significant amount of code, a monorepo can help ensure that these shared components are consistent across all projects. This is particularly beneficial for UI components, utility functions, or custom logic.

    +
    • +
  • +

    Unified CI/CD pipeline: A monorepo allows you to manage a single CI/CD pipeline, simplifying the automation process. This is useful when you want to ensure that all parts of your application are tested and deployed together, reducing the risk of version mismatches.

    +
    • +
  • +

    Simplified dependency management: Managing dependencies across multiple repositories can be complex and error-prone. With a monorepo, you can centralize dependency management, making it easier to maintain consistency and avoid version conflicts.

    +
    • +
  • +

    Synchronous release cycles: If your apps or services need to be released together, a monorepo makes it easier to coordinate these releases. This is often the case in large-scale enterprise applications where different parts of the system are closely interconnected.

    +
    • +
  • +

    Small to medium-sized teams: Monorepos work well for small to medium-sized teams. With everyone working in the same repository, it’s easier to collaborate, share code, and stay aligned on changes.

    +
    • +
+

When not to use a monorepo​

+
    +
  • +

    Large and unrelated projects: If your projects are large and unrelated, a monorepo can become unwieldy. The repository size might grow excessively, and it can become difficult to manage unrelated codebases together, leading to longer CI/CD times and more complex build processes.

    +
    • +
  • +

    Different lifecycles: When different projects have significantly different release cycles or stability requirements, maintaining them in a monorepo can introduce unnecessary complexity. For example, if one service is in active development while another is in maintenance mode, separate repositories might be more appropriate.

    +
    • +
  • +

    Security concerns: If your projects require different access controls or have varying levels of security requirements, a monorepo might not be suitable. Ensuring that sensitive parts of the codebase are protected can be more challenging in a monorepo setup.

    +
    • +
  • +

    Large, distributed teams: For large, distributed teams, a monorepo can become hard to manage. With many contributors, the repository can grow quickly, leading to longer build times and more complicated merges. In these cases, using separate repositories might be better, allowing different teams to work independently without slowing each other down.

    +
    • +
+

Common monorepo tools​

+

Existing monorepo tools can be divided in two types:

+
    +
  • Dependency managers
    • +
  • Build systems
    • +
+

Let's talk about each of them.

+

Dependency managers​

+

A dependency manager is a tool that automates the installation and management of a project's required libraries, ensuring compatibility and consistency.

+
ToolProsCons
Yarn WorkspacesBuilt-in support for monorepos.
Simplifies dependency management across packages.
Excellent community support and documentation.		Can be complex to configure initially.
Some issues with peer dependencies.
PnpmEfficient disk space usage with unique package storage.
Fast installation times.
Built-in support for monorepos.		Less mainstream adoption, leading to potential issues with community support.
Some tooling might not fully support Pnpm yet.
LernaGreat for managing multi-package repositories.
Supports independent versioning of packages.
Integrates well with Yarn Workspaces.		Stagnant for years, although maintained by Nx now.
Slower for large codebases.
Requires additional configuration for CI/CD.
+
info

Based on our experience, simplicity and community support, we recommend Yarn as a dependency manager.

+

Build systems​

+

A build system automates tasks like compiling code, running tests, and bundling assets, optimizing the development process.

+
ToolProsCons
NxFocuses on improving performance with advanced caching and task scheduling.
Great for large-scale enterprise applications.		Steeper learning curve.
May be overkill for smaller projects.
TurborepoHigh performance with built-in caching and parallel task execution.
Simplifies monorepo management with minimal configuration.		Less mature ecosystem compared to Yarn or Lerna.
Limited tooling support for some workflows.
+

Common monorepo setups for software apps​

+

Frontend apps and packages​

+
    +
  • /apps: Contains a set of frontend apps (e.g. React, Electron, React Native).
    • +
  • /packages: Contains shared packages used by frontend apps.
    • +
+

Use case: Ideal for projects that need to manage multiple frontend apps sharing a common set of utilities and packages.

+

Frontend and backend in a single monorepo​

+

Structure:

+
    +
  • /frontend: Contains the React Native app and other frontend components.
    • +
  • /backend: Contains the server-side code, typically a Node.js or Python backend.
    • +
  • /shared: Contains shared utilities, types, or components used by both frontend and backend.
    • +
+

Use case: Ideal for projects where the frontend and backend are tightly coupled and frequently share code, such as shared type definitions, utility functions, or API clients.

+

Monorepo with multiple microservices​

+

Structure:

+
    +
  • /service-auth: Contains the authentication service.
    • +
  • /service-payment: Contains the payment processing service.
    • +
  • /service-notifications: Contains the notification service.
    • +
  • /shared: Contains shared libraries, such as logging or database utilities.
    • +
+

Use case: Suitable for large-scale applications with multiple microservices that need to share common libraries or configurations.

+

Hybrid monorepo (web, mobile, and backend)​

+

Structure:

+
    +
  • /web: Contains the web application code, typically built with React or Next.js.
    • +
  • /mobile: Contains the React Native mobile app code.
    • +
  • /backend: Contains the backend services.
    • +
  • /shared: Contains shared components, utilities, or API clients.
    • +
+

Use case: Ideal for projects that need to maintain both web and mobile applications with a shared backend, ensuring that all parts of the system stay in sync.

+

Library and application in a single monorepo​

+

Structure:

+
    +
  • /library: Contains the core library code, which could be published as an npm package.
    • +
  • /app: Contains the application code that consumes the library.
    • +
  • /docs: Contains documentation for the library and application.
    • +
+

Use case: Best for projects where a core library is being developed alongside an application that consumes it, allowing for rapid iteration and testing.

+

Conclusion​

+

Choosing whether to use a monorepo and selecting the right setup and tool depends on your project's specific needs. Yarn Workspaces is generally the recommended choice due to its balance of simplicity, community support, and effectiveness in managing shared dependencies. However, other options like Lerna, Nx, Turborepo, and Pnpm offer unique advantages that might better suit your project depending on its scale, complexity, and specific requirements.

+

By carefully considering the pros and cons of each option and common monorepo setups, you can select the best strategy to streamline your development process and ensure the long-term maintainability of your codebase.

Is this page still up to date? Did it work for you?

Tags:
Last updated on by Felipe Peña
+ + \ No newline at end of file diff --git a/docs/recipes/PatchingBuildingAndroid/index.html b/docs/recipes/PatchingBuildingAndroid/index.html index b9f42902..fc1b36b1 100644 --- a/docs/recipes/PatchingBuildingAndroid/index.html +++ b/docs/recipes/PatchingBuildingAndroid/index.html @@ -10,8 +10,8 @@ - - + +

Patching/Building Android .aar From Source

Why?​

+

Patching/Building Android .aar From Source

Why?​

Sometimes, a situation arises when you might want to update the react-native Android source code without upgrading react-native itself. For example, there's a new bug on Android 12 where the application crashes due to some bug with the animation queue. The potential fix is available on the main (unreleased) branch, but your app version is a few patches behind. Another situation is when you simply can't upgrade your react-native version yet, but need a fix from future version. In these cases, you can use this approach to "patch" your Android source files and build new .aar binary and use that for your app.

Official Guides​

The official steps to build from source are provided by react-native and you can find them here.

@@ -85,6 +85,6 @@

Steps

Note: You'll most likely need to delete/re-install your node_modules as well as run ./android/gradlew clean.

-

Is this page still up to date? Did it work for you?

+

Is this page still up to date? Did it work for you?

\ No newline at end of file diff --git a/docs/recipes/PrepForEASBuild/index.html b/docs/recipes/PrepForEASBuild/index.html index 63271b00..0769c82e 100644 --- a/docs/recipes/PrepForEASBuild/index.html +++ b/docs/recipes/PrepForEASBuild/index.html @@ -10,8 +10,8 @@ - - + +
Skip to main content

Prepping Ignite for EAS Build

+

Prepping Ignite for EAS Build

This guide will teach you how to set up an Expo development build which prepares your project for native code via Config Plugins, but keeps you in Expo's managed workflow.

Appetizer​

Start with a fresh Ignite app, but choose the prebuild workflow:

diff --git a/docs/recipes/ReactNativeVisionCamera/index.html b/docs/recipes/ReactNativeVisionCamera/index.html index 728c9865..253cfaf8 100644 --- a/docs/recipes/ReactNativeVisionCamera/index.html +++ b/docs/recipes/ReactNativeVisionCamera/index.html @@ -10,8 +10,8 @@ - - + +

VisionCamera

+

VisionCamera

Overview​

VisionCamera is a powerful, high-performance React Native Camera library. It's both feature-rich and flexible! The library provides the necessary hooks and functions to easily integrate camera functionality in your app.

In this example, we'll take a look at wiring up a barcode scanner. This tutorial is written for the Ignite v9 Prebuild workflow, however it generally still applies to DIY or even a bare react-native project.

diff --git a/docs/recipes/Redux/index.html b/docs/recipes/Redux/index.html index 0964f13a..1c965808 100644 --- a/docs/recipes/Redux/index.html +++ b/docs/recipes/Redux/index.html @@ -10,8 +10,8 @@ - - + +

Redux

+

Redux

This guide will show you how to migrate a MobX-State-Tree project (Ignite's default) to Redux, using a newly created Ignite project as our example:

npx ignite-cli new ReduxApp --yes --removeDemo

If you are migrating an existing project these steps still apply, but you may need to migrate your existing state tree and other additional functionality.

diff --git a/docs/recipes/RemoveMobxStateTree/index.html b/docs/recipes/RemoveMobxStateTree/index.html index 2fbd5c83..b6e99c3a 100644 --- a/docs/recipes/RemoveMobxStateTree/index.html +++ b/docs/recipes/RemoveMobxStateTree/index.html @@ -10,8 +10,8 @@ - - + +

Remove Mobx-State-Tree

+

Remove Mobx-State-Tree

By default, Ignite uses MobX-State-Tree as the default state management solution. While we love MobX-State-Tree at Infinite Red, we understand the landscape is rich with great alternatives that you may want to use instead.

This guide will show you how to remove Mobx-State-Tree from an Ignite-generated project and get to a "blank slate" with no state management at all.

Steps​

diff --git a/docs/recipes/RequiringHardwareFeaturesWithExpo/index.html b/docs/recipes/RequiringHardwareFeaturesWithExpo/index.html index 6cdfe0ff..ec725574 100644 --- a/docs/recipes/RequiringHardwareFeaturesWithExpo/index.html +++ b/docs/recipes/RequiringHardwareFeaturesWithExpo/index.html @@ -10,8 +10,8 @@ - - + +

Requiring Hardware Features with Expo

+

Requiring Hardware Features with Expo

Overview​

iOS and Android allow you to specify specific hardware that your app needs in order to be able to run. When users go to download your app from the respective app stores, if their device doesn't meet this hardware requirement, the store will not allow the user to download the app to that device.

For this recipe, we're going to be creating an expo config plugin to add the required properties to our app's prebuild system so that users with devices that DO NOT have a front-facing camera or a microphone won't be able to download our app.

diff --git a/docs/recipes/SampleYAMLCircleCI/index.html b/docs/recipes/SampleYAMLCircleCI/index.html index 74e1f721..1c982085 100644 --- a/docs/recipes/SampleYAMLCircleCI/index.html +++ b/docs/recipes/SampleYAMLCircleCI/index.html @@ -10,8 +10,8 @@ - - + +

Sample YAML for CircleCi for Ignite

Sample YAML File​

+

Sample YAML for CircleCi for Ignite

Sample YAML File​

# Javascript Node CircleCI 2.0 configuration file
#
# Check https://circleci.com/docs/2.0/language-javascript/ for more details
#

defaults: &defaults
  docker:
    # Choose the version of Node you want here
    - image: circleci/node:10.11
  working_directory: ~/repo

version: 2
jobs:
  setup:
    <<: *defaults
    steps:
      - checkout
      - restore_cache:
          name: Restore node modules
          keys:
            - v1-dependencies-{{ checksum "package.json" }}
            # fallback to using the latest cache if no exact match is found
            - v1-dependencies-
      - run:
          name: Install dependencies
          command: |
            yarn install
      - save_cache:
          name: Save node modules
          paths:
            - node_modules
          key: v1-dependencies-{{ checksum "package.json" }}

  tests:
    <<: *defaults
    steps:
      - checkout
      - restore_cache:
          name: Restore node modules
          keys:
            - v1-dependencies-{{ checksum "package.json" }}
            # fallback to using the latest cache if no exact match is found
            - v1-dependencies-
      - run:
          name: Install React Native CLI and Ignite CLI
          command: |
            sudo npm i -g ignite-cli react-native-cli
      - run:
          name: Run tests
          command: yarn ci:test # this command will be added to/found in your package.json scripts

  publish:
    <<: *defaults
    steps:
      - checkout
      - run: echo "//registry.npmjs.org/:_authToken=$NPM_TOKEN" >> ~/.npmrc
      - restore_cache:
          name: Restore node modules
          keys:
            - v1-dependencies-{{ checksum "package.json" }}
            # fallback to using the latest cache if no exact match is found
            - v1-dependencies-
      # Run semantic-release after all the above is set.
      - run:
          name: Publish to NPM
          command: yarn ci:publish # this will be added to your package.json scripts

workflows:
  version: 2
  test_and_release:
    jobs:
      - setup
      - tests:
          requires:
            - setup
      - publish:
          requires:
            - tests
          filters:
            branches:
              only: master

Is this page still up to date? Did it work for you?

Tags:
Last updated on by Robin Heinze
\ No newline at end of file diff --git a/docs/recipes/SelectFieldWithBottomSheet/index.html b/docs/recipes/SelectFieldWithBottomSheet/index.html index f78ada4c..4f94f3c9 100644 --- a/docs/recipes/SelectFieldWithBottomSheet/index.html +++ b/docs/recipes/SelectFieldWithBottomSheet/index.html @@ -10,8 +10,8 @@ - - + +

SelectField using react-native-bottom-sheet

+

SelectField using react-native-bottom-sheet

In this guide, we'll be creating a SelectField component by extending the TextField with a scrollable options View and additional props to handle its customization.

We will be using the react-native-bottom-sheet library for the options list, the ListItem component for displaying individual options, and the TextField component for opening the options list and displaying selected options.

diff --git a/docs/recipes/SwitchBetweenExpoGoCNG/index.html b/docs/recipes/SwitchBetweenExpoGoCNG/index.html index 0e237191..e3ef7df7 100644 --- a/docs/recipes/SwitchBetweenExpoGoCNG/index.html +++ b/docs/recipes/SwitchBetweenExpoGoCNG/index.html @@ -10,8 +10,8 @@ - - + +

Switch a Project Between Expo Go and Expo CNG

+

Switch a Project Between Expo Go and Expo CNG

If you created an Ignite project using the Expo Go workflow and you need to transition to Expo CNG (Continuous Native Generation) or visa versa, this guide will teach you how to reconfigure your project.

Expo Go -> Expo CNG​

If you started with Expo Go but now need to add a library with native code, create your own custom native code, or modify native project configuration, you'll no longer be able to run your app inside Expo Go.

diff --git a/docs/recipes/Theming-Emotion/index.html b/docs/recipes/Theming-Emotion/index.html index 5500e5df..ff369066 100644 --- a/docs/recipes/Theming-Emotion/index.html +++ b/docs/recipes/Theming-Emotion/index.html @@ -10,8 +10,8 @@ - - + +

Theming Ignite

+

Theming Ignite

When it comes to styling we acknowledge the popularity and effectiveness of libraries like styled-components, emotion.js and unistyles. Our boilerplate is designed to work seamlessly with these styling solutions, offering you the flexibility to choose the one that aligns with your preferences and project requirements.

The theming system in Ignite Boilerplate is crafted to be adaptable and easy to customize. By simply replacing colors and fonts through the designated theme files, you can tailor the look and feel of your application.

Using Emotion​

diff --git a/docs/recipes/Theming-StyledComponents/index.html b/docs/recipes/Theming-StyledComponents/index.html index c178da64..bb6baf62 100644 --- a/docs/recipes/Theming-StyledComponents/index.html +++ b/docs/recipes/Theming-StyledComponents/index.html @@ -10,8 +10,8 @@ - - + +

Theming Ignite

+

Theming Ignite

When it comes to styling we acknowledge the popularity and effectiveness of libraries like styled-components, emotion.js and unistyles. Our boilerplate is designed to work seamlessly with these styling solutions, offering you the flexibility to choose the one that aligns with your preferences and project requirements.

The theming system in Ignite Boilerplate is crafted to be adaptable and easy to customize. By simply replacing colors and fonts through the designated theme files, you can tailor the look and feel of your application.

Using styled-components​

diff --git a/docs/recipes/Theming-Unistyles/index.html b/docs/recipes/Theming-Unistyles/index.html index 70a727aa..a6be7bf8 100644 --- a/docs/recipes/Theming-Unistyles/index.html +++ b/docs/recipes/Theming-Unistyles/index.html @@ -10,8 +10,8 @@ - - + +

Theming Ignite

+

Theming Ignite

When it comes to styling we acknowledge the popularity and effectiveness of libraries like styled-components, emotion.js and unistyles. Our boilerplate is designed to work seamlessly with these styling solutions, offering you the flexibility to choose the one that aligns with your preferences and project requirements.

The theming system in Ignite Boilerplate is crafted to be adaptable and easy to customize. By simply replacing colors and fonts through the designated theme files, you can tailor the look and feel of your application.

Using Unistyles​

diff --git a/docs/recipes/TypeScriptBaseURL/index.html b/docs/recipes/TypeScriptBaseURL/index.html index 3d7ff88d..f5903cfe 100644 --- a/docs/recipes/TypeScriptBaseURL/index.html +++ b/docs/recipes/TypeScriptBaseURL/index.html @@ -10,8 +10,8 @@ - - + +

TypeScript baseUrl Configuration

+

TypeScript baseUrl Configuration

Overview​

Depending on your project structure, sometimes you'll end up with longer relative imports like this:

import { Thing } from "../../../../../components/thing";
diff --git a/docs/recipes/UnrenderedItemInScrollView/index.html b/docs/recipes/UnrenderedItemInScrollView/index.html index 53692c63..04095193 100644 --- a/docs/recipes/UnrenderedItemInScrollView/index.html +++ b/docs/recipes/UnrenderedItemInScrollView/index.html @@ -10,8 +10,8 @@ - - + +

Scrolling to a location that hasn't been rendered using FlatList or SectionList

Calling scrollViewRef.current.scrollToLocation() on a React Native FlatList or SectionList will fail on occasion because it can't scroll to a location that hasn't been rendered yet.

+

Scrolling to a location that hasn't been rendered using FlatList or SectionList

Calling scrollViewRef.current.scrollToLocation() on a React Native FlatList or SectionList will fail on occasion because it can't scroll to a location that hasn't been rendered yet.

The solution to this is implementing onScrollToIndexFailed with some sort of recovery functionality to keep trying the scroll. This is a Higher Order Component (HOC) for SectionList that handles this for us.

This component basically tries over and over to scroll to the requested location until it gets it right and no longer calls onScrollToIndexFailed.

import * as React from 'react';
import { SectionList, SectionListProps, SectionListScrollParams } from 'react-native';

interface SectionListHandle {
  scrollToLocation: (params: SectionListScrollParams) => void;
}

/**
 * This is a wrapper around react-native's SectionList that adds protection against scrolling to an
 * unknown (not rendered yet) location. This is useful for cases where the user wants to scroll to a
 * position very far down the list but we haven't rendered that far yet.
 *
 * This adds onScrollToIndexFailed property to SectionList so that if the scroll fails, we calculate the approximate
 * scroll position, scroll there, and then try again to get the exact position requested.
 *
 * Essentially, it's a "guess the position and retry the operation" strategy until the list is scrolled to the
 * correct location.
 */
export const ScrollProtectedSectionList = React.forwardRef<
  SectionListHandle,
  SectionListProps<any, any>
>((props, forwardedRef) => {
  const internalRef = React.useRef<SectionList>(null);
  const [lastScrollRequest, setLastScrollRequest] = React.useState<SectionListScrollParams>();
  const timeout = React.useRef<ReturnType<typeof setTimeout>>();

  const onScrollToIndexFailed = (info: {
    index: number;
    highestMeasuredFrameIndex: number;
    averageItemLength: number;
  }) => {
    console.log('ScrollProtectedSectionList.onScrollToIndexFailed', info);

    // Calculate the possible position of the item and scroll there using the internal scroll responder.
    const offset = info.averageItemLength * info.index;
    internalRef.current?.getScrollResponder()?.scrollTo({ x: 0, y: offset, animated: false });

    // If we know exactly where we want to scroll to, we can just scroll now since the item is likely visible.
    // Otherwise it'll call this function recursively again.
    if (lastScrollRequest) {
      timeout.current = setTimeout(() => {
        internalRef.current?.scrollToLocation(lastScrollRequest);
      }, 100);
    }
  };

  // Clear the timeout if it still exists when the component unmounts.
  React.useEffect(() => {
    return () => timeout.current && clearTimeout(timeout.current);
  }, []);

  React.useImperativeHandle(
    forwardedRef,
    () => ({
      scrollToLocation: (params: SectionListScrollParams) => {
        internalRef.current?.scrollToLocation(params);
        setLastScrollRequest(params);
      },
    }),
    [internalRef],
  );

  return <SectionList {...props} ref={internalRef} onScrollToIndexFailed={onScrollToIndexFailed} />;
});

Is this page still up to date? Did it work for you?

diff --git a/docs/recipes/UpdatingDependencies/index.html b/docs/recipes/UpdatingDependencies/index.html index 01c044b6..fdaabd2a 100644 --- a/docs/recipes/UpdatingDependencies/index.html +++ b/docs/recipes/UpdatingDependencies/index.html @@ -10,8 +10,8 @@ - - + +

Updating Dependencies with Yarn Audit, Outdated and Upgrade

If you get a bunch of warnings in the git command output about vulnerabilities, similar to this: remote: Github found 80 vulnerabilities on <branch>..., you can examine these vulnerabilities with yarn audit, get a list of outdated packages with yarn outdated, and update each dependency using yarn update

+

Updating Dependencies with Yarn Audit, Outdated and Upgrade

If you get a bunch of warnings in the git command output about vulnerabilities, similar to this: remote: Github found 80 vulnerabilities on <branch>..., you can examine these vulnerabilities with yarn audit, get a list of outdated packages with yarn outdated, and update each dependency using yarn update

Yarn Audit Checks for known security issues with the installed packages. Issue the command from the root of your project. The output is a list of known issues.

Usage:

yarn audit
diff --git a/docs/recipes/UpdatingIgnite/index.html b/docs/recipes/UpdatingIgnite/index.html index 1d8e3ba8..86649bd2 100644 --- a/docs/recipes/UpdatingIgnite/index.html +++ b/docs/recipes/UpdatingIgnite/index.html @@ -10,8 +10,8 @@ - - + +

Updating Ignite boilerplate with ignite-diff-purge

Many React Native developers aks this question:

+

Updating Ignite boilerplate with ignite-diff-purge

Many React Native developers aks this question:

How can I update my Ignite boilerplate with the latest changes from the Ignite boilerplate?

diff --git a/docs/recipes/UsingScreenReaders/index.html b/docs/recipes/UsingScreenReaders/index.html index 15c9d14f..6db3b36e 100644 --- a/docs/recipes/UsingScreenReaders/index.html +++ b/docs/recipes/UsingScreenReaders/index.html @@ -10,8 +10,8 @@ - - + +

Using Screen Readers

+

Using Screen Readers

iOS​

On a simulator​

Setting it up diff --git a/docs/recipes/Zustand/index.html b/docs/recipes/Zustand/index.html index c449418d..bbd14657 100644 --- a/docs/recipes/Zustand/index.html +++ b/docs/recipes/Zustand/index.html @@ -10,8 +10,8 @@ - - + +

Zustand

+

Zustand

Zustand is a "bearbones" state management solution (hence the cute bear mascot). Its a relatively simple and unopinionated option to manage application state, with a hooks-based API for easy use in a React app.

This guide will show you how to migrate a MobX-State-Tree project (Ignite's default) to Zustand, using a new Ignite project as an example:

diff --git a/docs/tags/accessibility/index.html b/docs/tags/accessibility/index.html index 8c430bd6..46b0adfd 100644 --- a/docs/tags/accessibility/index.html +++ b/docs/tags/accessibility/index.html @@ -10,8 +10,8 @@ - - + +
+
updated 5 weeks ago
Animation Image

Backed By A Community of React Native Experts

The Ignite Cookbook isn’t just a random group of code snippets. It’s a curated collection of usable code samples that the Infinite Red team’s used in their own React Native projects. Having worked with some of the biggest clients in the tech industry, we know a thing or two about keeping our code to a high standard. You can code confidently!

Animation ImageAnimation ImageAnimation ImageAnimation ImageAnimation ImageAnimation ImageAnimation ImageAnimation ImageAnimation ImageAnimation ImageAnimation Image

Freshly added to the cookbook

Theming Ignite with Emotion.js

Published on October 2nd, 2024 by Mark Rickert

Theming Ignite with styled-components

Published on October 2nd, 2024 by Mark Rickert

Theming Ignite with Unistyles

Published on October 2nd, 2024 by Mark Rickert

Migrating from i18n-js to react-i18next

Published on September 25th, 2024 by Felipe Peña

View all recipes
\ No newline at end of file diff --git a/search/index.html b/search/index.html index 2195cd8f..09fef098 100644 --- a/search/index.html +++ b/search/index.html @@ -10,8 +10,8 @@ - - + +