👨‍💻 What We Built

We created a chat screen and a conversation list using @cometchat/chat-sdk-react-native, tailored for session-based communication—meaning chats are only active during a scheduled window (e.g., therapy, tutoring, consultations).

🔑 Key Features

• ✅ Chat starts and ends based on appointment schedule
• 📷 Real-time messaging with image support
• ✍️ Typing indicators, user online/offline status
• ⏱ Countdown timer for active session
• 🛑 Automatic chat termination after time limit
• 🧼 Media validation (no GIFs, file size checks)
• 📜 Optimized message history loading

📱 Conversations Screen — Recent Contacts & History

The Conversations.tsx screen fetches the user’s recent chats and displays:

• A horizontal list of Recent Contacts
• A vertical list of Active Conversations

📦 Fetching Conversations

const fetchConversations = async (allConversations: boolean) => {
  const conversationsList =
    await CometChatService.getInstance().fetchNextConversations(allConversations);
setConversations(prevConversations => {
    const processedConversations = conversationsList.map(conv => ({
      conversationWith: conv.conversationWith,
      lastMessage: {
        text: conv.lastMessage?.text || 'Image',
        sentAt: conv.lastMessage?.sentAt || Date.now(),
      },
      unreadMessageCount: conv.unreadMessageCount || 0,
      conversationId: conv.conversationId,
    }));
    return [...processedConversations].sort(
      (a, b) => (b.lastMessage?.sentAt || 0) - (a.lastMessage?.sentAt || 0)
    );
  });
};

🧭 Navigating to a Chat

<TouchableOpacity
  onPress={() =>
    navigation.navigate(SCREEN_NAME.CHAT_SCREEN, {
      senderDetails: item.conversationWith,
    })
  }>

💬 Chat Screen — Real-Time Messaging with Media

The ChatScreen.tsx handles:

• Realtime message rendering
• User presence
• Scheduled session restrictions
• Media file uploads

📤 Message Sending Logic

const handleSend = async () => {
  const sentMessage = await CometChatService.getInstance().sendMessage(
    senderDetails.uid,
    message.trim(),
  );

const newMessage: ChatMessage = {
    _id: sentMessage.id,
    createdAt: new Date(sentMessage.sentAt * 1000),
    user: {
      _id: sentMessage.sender.uid,
      name: sentMessage.sender.name,
    },
    messageText: sentMessage.text,
    image: sentMessage.sender.avatar,
  };
  setMessages(prev => [newMessage, ...prev]);
  setMessage('');
};

🖼 Media Message Handling (Camera & Gallery)

Media validation and image message sending:

const handleSendMediaMessage = async (mediaFile: MediaData) => {
  const sentMessage = await CometChatService.getInstance().sendMediaMessage(
    senderDetails.uid,
    mediaFile,
  );

const newMessage: ChatMessage = {
    _id: sentMessage.id,
    createdAt: new Date(sentMessage.sentAt * 1000),
    user: {
      _id: sentMessage.sender.uid,
      name: sentMessage.sender.name,
    },
    messageText: 'User_has_sent_an_image',
    image: sentMessage.sender.avatar,
    mediaUrl: sentMessage.data?.url,
  };
  setMessages(prev => [newMessage, ...prev]);
};

Rejecting GIFs and large files:

if (type === 'image/gif') {
  errorToast('GIFs are not allowed');
  return;
}
if (validateFileSize(fileSize)) {
  errorToast(FILE_EXCEED_ERROR_MESSAGE);
  return;
}

🕓 Session Timer & Auto Chat-End

If the user has a scheduled booking, chat only opens during that window.

⏳ Start Timer

const startTimer = () => {
  BackgroundTimer.runBackgroundTimer(() => {
    setRemainingTime(prev => {
      if (prev <= 1) {
        BackgroundTimer.stopBackgroundTimer();
        handleAutoChatEnd();
        return 0;
      }
if (prev === 300 && !alertShown) {
        errorToast('The chat will end in 5 minutes.');
        setAlertShown(true);
      }
      return prev - 1;
    });
  }, 1000);
};

🔚 Auto-End Logic

const handleAutoChatEnd = () => {
  if (chatEndTriggeredRef.current) return;

chatEndTriggeredRef.current = true;
  dispatch(
    endChat({
      data: apiPayload,
      cb: () => {
        setIsConfirmText(false);
        setIsConfirmChatEnd(true);
      },
    }),
  );
};

🔄 Typing & User Presence

Handle real-time presence and typing indicators using CometChat events.

CometChatService.getInstance().attachMessageListener(
  listenerId,
  (event, message) => {
    if (event === MessageEvents.TYPING_STARTED) setIsTyping(true);
    else if (event === MessageEvents.TYPING_ENDED) setIsTyping(false);
    else if (event === MessageEvents.USER_ONLINE) setIsUserOnline(true);
    else if (event === MessageEvents.USER_OFFLINE) setIsUserOnline(false);
  }
);

Typing trigger based on keyboard visibility:

useEffect(() => {
  if (isKeyboardVisible) {
    CometChat.startTyping(new CometChat.TypingIndicator(senderDetails.uid, 'user'));
  } else {
    CometChat.endTyping(new CometChat.TypingIndicator(senderDetails.uid, 'user'));
  }
}, [isKeyboardVisible]);

🧠 Final Thoughts

Building a real-time, session-aware chat interface involves much more than just messaging SDK integration.

By layering:

• ⏱ session timers
• 🛂 role-based access control
• 🚨 UI feedback (toasts)
• 🔒 file validation
• 🔁 real-time hooks

…we ensure a robust user experience that respects both UX and business rules.

🛠 Tech Stack

• React Native
• CometChat SDK
• Redux, React Navigation
• react-native-background-timer
• Moment.js, FlatList

👨‍💼 Work With Me

If you’re building a React Native or iOS native app and need an experienced engineer to ship fast, scalable, and reliable solutions, I’m available for freelance and contract work.

📫 Let’s connect on LinkedIn or reach out via email to discuss your project!

In this article, we’ll explore how React Hook Form prevents unnecessary re-renders and improves the user experience in React Native applications.

🔥 Why Use React Hook Form in React Native?

React Hook Form offers multiple benefits over traditional form-handling methods, likeuseState:

✅ Minimal Re-Renders → Only updates relevant fields, unlike. useState ✅ Optimised Performance → Uses uncontrolled components. ✅ Simplified Validation → Built-in support for validation rules. ✅ Lightweight → No additional dependencies like Formik.

Implementing React Hook Form in React Native

First, install:react-hook-form

npm install react-hook-form

Here’s a simple login form using React Hook Form:

import React from 'react';
import {Text, TextInput, View} from 'react-native';
import {useForm, Controller} from 'react-hook-form';
import styles from './styles';
import {Button} from '..';

type LoginFormData = {
  email: string;
  password: string;
  isSavePasswordEnable: boolean;
};
const LoginForm = () => {
  const {
    control,
    handleSubmit,
    formState: {isValid},
  } = useForm<LoginFormData>({
    defaultValues: {
      email: '',
      password: '',
      isSavePasswordEnable: false,
    },
    mode: 'onChange',
    reValidateMode: 'onChange',
  });
  console.log('isValid', isValid);

  const onSubmit = () => {};
  return (
    <View style={styles.container}>
      <Text style={styles.welcomeMessage}>Welcome to React Native </Text>
      <Controller
        control={control}
        rules={{
          required: true,
          pattern: /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$/,
        }}
        render={({field: {onChange, onBlur, value}}) => (
          <TextInput
            placeholder="enter email address *"
            style={styles.inputContainer}
            onChangeText={onChange}
            onBlur={onBlur}
            value={value}
          />
        )}
        name="email"
      />
      <View style={styles.sizeBox12} />
      <Controller
        control={control}
        rules={{
          required: true,
          minLength: 5,
        }}
        render={({field: {onChange, onBlur, value}}) => (
          <TextInput
            placeholder="enter password *"
            style={styles.inputContainer}
            value={value}
            secureTextEntry
            onChangeText={onChange}
            onBlur={onBlur}
          />
        )}
        name="password"
      />
      <View style={styles.sizeBox20} />
      <Button
        disabled={!isValid}
        title="Login"
        onPress={handleSubmit(onSubmit)}
      />
    </View>
  );
};

export default LoginForm;

⚡ How React Hook Form Prevents Re-Renders

Uncontrolled Components

Unlike,useState RHF registers inputs as uncontrolled components, meaning they don’t store their value in state on every keystroke. This reduces unnecessary re-renders.

Optimized State Management

RHF only updates the field that changed, not the entire form. This improves performance by avoiding unnecessary re-renders.

Validation Without Re-Renders

With mode: 'onChange' the field without triggering a full re-render, making the UI more responsive.

📌 Example: Compare RHF vs. useState Re-Renders

Using useState:

const [email, setEmail] = useState('');
const [password, setPassword] = useState('');

<TextInput value={email} onChangeText={(text) => setEmail(text)} />
<TextInput value={password} onChangeText={(text) => setPassword(text)} />

Every keystroke triggers a full re-render, which is bad for performance. RHF avoids this.

With react-hook-form:

<Controller
  control={control}
  render={({ field: { onChange, value } }) => (
    <TextInput value={value} onChangeText={onChange} />
  )}
  name="email"
/>

Now, React only updates the specific field, preventing full re-renders!

🎯 Key Takeaways

✅ React Hook Form is more efficient than useState for forms.
✅ Prevents unnecessary re-renders by using uncontrolled components.
✅ Validates inputs efficiently without extra renders.
✅ Improves app performance, especially in large forms.

Using React Hook Form in your React Native apps leads to a better user experience by ensuring smooth, lag-free form interactions. Try it out and see the difference! 🚀

What is Prop Drilling?

Props drilling occurs when you pass data or functions from a parent component down through several layers of child components, even if the intermediate components don’t need or use that data.

import React, { useState } from 'react';
import {View} from 'react-native';
import Child from './Child';

const Parent = () => {
  const [user, setUser] = useState('John Doe');
  
  return (
    <View>
      <Child user={user} />
    </View>
  );
};

// Child.js
import React from 'react';
import {View} from 'react-native';
import Grandchild from './Grandchild';

const Child = ({ user }) => {
  return (
    <View>
      <Grandchild user={user} />
    </View>
  );
};

// Grandchild.js
import React from 'react';
import {View,Text} from 'react-native';

const Grandchild = ({ user }) => {
  return <View>
          <Text>Hello, {user} </Text>
         </View>;
};

export default Grandchild;

In this example, the user state in the Parent component is passed down to Grandchild, but it goes through the Child component without being used there. This is an example of prop drilling.

The React Context API solves this problem: prop drilling. It allows you to share state across components without manually passing props down every level of the component tree.

Create Context

import React, {createContext, useState} from 'react';

type ThemeMode = 'light' | 'dark';

interface IThemeContext {
  theme: ThemeMode;
  setTheme: React.Dispatch<React.SetStateAction<IThemeContext['theme']>>;
}

const ThemeContext = createContext<IThemeContext | null>(null);

• createContext is used to create a context for managing the theme in the application.
• The context is initialized with null because by default, the context value is null before it’s provided by the ThemeContextProvider.
• IThemeContextis the interface that defines the shape of the context, ensuring that any consumer of the context will expect a theme (which is of type 'light' | 'dark') and a setTheme function to update the theme.

Creating the Context Provider

import React, {createContext, useState} from 'react';

type ThemeMode = 'light' | 'dark';

interface IThemeContext {
  theme: ThemeMode;
  setTheme: React.Dispatch<React.SetStateAction<IThemeContext['theme']>>;
}

const ThemeContext = createContext<IThemeContext | null>(null);

const ThemeContextProvider = ({children}: React.PropsWithChildren<{}>) => {
  const [theme, setTheme] = useState<IThemeContext['theme']>('light');

  return (
    <ThemeContext.Provider value={{theme, setTheme}}>
      {children}
    </ThemeContext.Provider>
  );
};

• ThemeContextProvider is a React component that uses useState to manage the theme state.
• The provider provides the theme and setTheme to its child components by passing them as the value prop to the ThemeContext.Provider.
• useState<IThemeContext['theme']>('light')initializes the theme state to 'light'. The type IThemeContext['theme'] ensures that the theme state only accepts 'light' or 'dark'.

Creating the useContextWrapper Hook

import React, {useContext} from 'react';

interface IConfig {
  contextName: string;
  providerName: string;
}

const useContextWrapper = <T,>(
  context: React.Context<T>,
  config: IConfig,
): T => {
  const contextValue = useContext(context);
  const {contextName, providerName} = config;

  if (!contextValue) {
    throw new Error(`${contextName} must be used within a ${providerName}`);
  }

  return contextValue;
};

export {useContextWrapper};

Explanation:

1. Generics (<T,>): The hook is generic, allowing it to work with any context type. The T represents the type of the context value, ensuring that the type is inferred and checked correctly when you consume the context.
2. Error Handling: The hook ensures that the contextValue is not null. If it is, it throws an error with a helpful message indicating which context and provider were involved. This is useful for debugging when a component is not wrapped in the correct provider.

Why Do We Need a useContextWrapper Hook?

React useContext hook allows you to consume a context value in a component, but if the context is used outside of its corresponding provider, it will return null. This could lead to subtle bugs and crashes in your application.

The useContextWrapper hook adds an additional layer of safety by throwing an error when a context is consumed outside of its provider, ensuring that your app behaves as expected.

Use the useContextWrapper Hook in the useThemeContext Hook

const useThemeContext = () =>
  useContextWrapper(ThemeContext, {
    contextName: 'ThemeContext',
    providerName: 'ThemeContextProvider',
  });

• useThemeContext wraps useContextWrapper to consume the ThemeContext safely.
• The hook will throw an error if it is used outside of ThemeContextProvider.

Using the useThemeContext Hook in Component

import React from 'react';
import { View, Text, Button, StyleSheet } from 'react-native';
import { useThemeContext } from '../context/themeContext';

const ComponentA = () => {
  const context = useThemeContext();

  if (!context) return null;

  const { theme, setTheme } = context;

  const toggleTheme = () => {
    setTheme(theme === 'light' ? 'dark' : 'light');
  };

  console.log(`ComponentA rendering...`);

  return (
    <View style={styles.container}>
      <Text style={styles.text}>The current theme is {theme}</Text>
      <Button title="Toggle Theme" onPress={toggleTheme} />
    </View>
  );
};

const styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
  },
  text: {
    fontSize: 18,
    marginBottom: 10,
  },
});

export default ComponentA;

Conclusion

Using React Context for managing global state is an essential pattern in modern React applications. By combining it with TypeScript and a custom useContextWrapper hook, we can make context consumption much safer and prevent common mistakes that lead to runtime errors.

Forceios simplifies the process of integrating iOS mobile apps with the Salesforce Platform by leveraging the power of the Salesforce Mobile SDK for iOS, making it easier for developers to get started.

iOS Basic Requirements for Mobile SDK Development

Before diving into the development process, there are a few essential prerequisites. Here’s what you’ll need:

1. Salesforce Setup:

• A Salesforce Developer Edition organization with a connected app.
  This is necessary for authenticating your app with Salesforce and accessing its APIs.

2. iOS Development Requirements (for Mobile SDK 11.1 and above):

• iOS SDK:
• Deployment Target: iOS 15 or later
• Base SDK: iOS 16 or later
• Xcode Version: Xcode 14 or later
  (I recommend using the latest version of Xcode to ensure compatibility and access to the newest tools and features.)

These requirements form the foundation for developing iOS applications that integrate seamlessly with Salesforce via the Salesforce Mobile SDK.

Creating an iOS Application: Two Approaches

There are two main ways to create an iOS app that integrates with Salesforce:

1. Creating iOS Applications Using Forceios
2. Creating iOS Applications Manually Using Xcode

Let’s explore both options.

1. Creating iOS Applications Using Forceios

The Forceios NPM package simplifies the creation of iOS apps by providing built-in templates for Salesforce integration. Here’s how you can get started:

Step 1: Install Forceios

To begin, install the Forceios package globally on your macOS machine. Open your terminal and run the following command.

sudo npm install forceios -g

Step 2: Create Your iOS App

Once the package is installed, you can create your iOS app using the following command:

forceios create [ - apptype=application_type (native_swift or native, leave empty for native_swift)] \
 - appname=application_name \
 - packagename=app_package_identifier (e.g., com.mycompany.myapp) \
 - organization=organization_name \
[ - outputdir=output_directory (leave empty for current directory)]

Command Breakdown:

• — apptype: Specify the application type. Leave empty for native_swift (default) or choose native for other options.
• — appname: Define the name of your application.
• — packagename: Set the unique package identifier for your app (e.g., com.mycompany.myapp).
• — organization: Enter your organization’s name.
• — outputdir: Optionally specify a directory where the app should be created. Leave empty to use the current directory.

After running this command, Forceios will scaffold a new iOS app preconfigured for Salesforce integration using the Salesforce Mobile SDK.

2. Creating iOS Applications Manually Using Xcode

Alternatively, you can manually create an iOS app and integrate the Salesforce Mobile SDK yourself. This method requires more hands-on configuration but offers full flexibility.

Step-by-Step Guide:

1. Create a New Xcode Project:
   Start by creating a new iOS project in Xcode and choose the appropriate template (e.g., iOS App).
2. Install CocoaPods and the Salesforce Mobile SDK:
   If you haven’t already, install CocoaPods by following the instructions at cocoapods.org.
3. Set Up Your Podfile: In your Xcode project, create or update the Podfile to include the Salesforce Mobile SDK. Add the SalesforceMobileSDK-iOS-Specs repo as the source (it should be the first entry in your Podfile):

target 'YourAppName' do
use_frameworks!
source 'https://github.com/forcedotcom/SalesforceMobileSDK-iOS-Specs.git' # needs to be first
source 'https://github.com/CocoaPods/Specs.git'
pod 'SalesforceSDKCore'
end

Explanation of Pods:

• SalesforceSDKCore: Implements OAuth, passcodes, networking, and REST APIs.
• SmartStore: Provides secure offline storage, dependent on SalesforceSDKCore.
• MobileSync: Implements offline synchronization, dependent on SmartStore.
• SalesforceAnalytics: Tracks usage statistics for the Mobile SDK.
• SalesforceSDKCommon: Includes utilities shared throughout the SDK.
• FMDB: A third-party module used by the SDK for local database storage.

4. Install Dependencies: Run the following command to install the pods:

pod install

After installation, open the .xcworkspace file to work with your project.

5. Update AppDelegate File

• Import MobileSync and initialize the SDK in your AppDelegate.swift file:

import MobileSync

override init() {
        super.init()
        MobileSyncSDKManager.initializeSDK()
     }

6. Update SceneDelegate File

• You will also need to update your SceneDelegate.swift to handle the app’s lifecycle and authentication flows, especially if you’re using QR-based login or deep linking.

import UIKit
import SwiftUI
import MobileSync
import SalesforceSDKCore

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?
    
    // MARK: - UISceneDelegate Implementation
    
    func scene(_ scene: UIScene,
               openURLContexts urlContexts: Set<UIOpenURLContext>)
    {
  
        // Uncomment when enabling log in via Salesforce UI Bridge API generated QR codes.
        /*
         * Note: The app's Info.plist must be updated with the URL type, scheme
         * and any other desired options to support custom URL scheme deep links
         * for the QR login code.  It is possible to use universal links for
         * this also so long as the app is configured, the UI bridge API
         * parameters are obtained and passed to
         * LoginTypeSelectionViewController.loginWithFrontdoorBridgeUrl
         */
//        // When the app process was running and receives a custom URL scheme deep link, use login QR code if applicable.
//        if let urlContext = urlContexts.first {
//            useQrCodeLogInUrl(urlContext.url)
//        }
    }
    
    func scene(_ scene: UIScene,
               willConnectTo session: UISceneSession,
               options connectionOptions: UIScene.ConnectionOptions)
    {
        guard let windowScene = (scene as? UIWindowScene) else { return }
        self.window = UIWindow(frame: windowScene.coordinateSpace.bounds)
        self.window?.windowScene = windowScene
       
        AuthHelper.registerBlock(forCurrentUserChangeNotifications: {
           self.resetViewState {
               self.setupRootViewController()
           }
        })
        
        // Uncomment when enabling log in via Salesforce UI Bridge API generated QR codes.
        // When the app process was not running and receives a custom URL scheme deep link, use login QR code if applicable.
//        if let urlContext = connectionOptions.urlContexts.first {
//            useQrCodeLogInUrl(urlContext.url)
//        }
    }

    func sceneDidDisconnect(_ scene: UIScene) {
        // Called as the scene is being released by the system.
        // This occurs shortly after the scene enters the background, or when its session is discarded.
        // Release any resources associated with this scene that can be re-created the next time the scene connects.
        // The scene may re-connect later, as its session was not neccessarily discarded (see `application:didDiscardSceneSessions` instead).
    }

    func sceneDidBecomeActive(_ scene: UIScene) {
        // Called when the scene has moved from an inactive state to an active state.
        // Use this method to restart any tasks that were paused (or not yet started) when the scene was inactive.
    }

    func sceneWillResignActive(_ scene: UIScene) {
        // Called when the scene will move from an active state to an inactive state.
        // This may occur due to temporary interruptions (ex. an incoming phone call).
    }

    func sceneWillEnterForeground(_ scene: UIScene) {
        // Called as the scene transitions from the background to the foreground.
        // Use this method to undo the changes made on entering the background.
        self.initializeAppViewState()
        AuthHelper.loginIfRequired {
            self.setupRootViewController()
        }
    }

    func sceneDidEnterBackground(_ scene: UIScene) {
        // Called as the scene transitions from the foreground to the background.
        // Use this method to save data, release shared resources, and store enough scene-specific state information
        // to restore the scene back to its current state.
    }
    
    // MARK: - Private Methods
    
   func initializeAppViewState() {
       if (!Thread.isMainThread) {
           DispatchQueue.main.async {
               self.initializeAppViewState()
           }
           return
       }
       
       self.window?.rootViewController = InitialViewController(nibName: nil, bundle: nil)
       self.window?.makeKeyAndVisible()
   }
   
   func setupRootViewController() {
       // Setup store based on config userstore.json
       MobileSyncSDKManager.shared.setupUserStoreFromDefaultConfig()
       // Setup syncs based on config usersyncs.json
       MobileSyncSDKManager.shared.setupUserSyncsFromDefaultConfig()
    
       self.window?.rootViewController = UIHostingController(
           rootView: AccountsListView()
       )
   }
   
   func resetViewState(_ postResetBlock: @escaping () -> ()) {
       if let rootViewController = self.window?.rootViewController {
           if let _ = rootViewController.presentedViewController {
               rootViewController.dismiss(animated: false, completion: postResetBlock)
               return
           }
       }
       postResetBlock()
   }
    
    
}

Conclusion

Both Forceios and the manual Xcode setup offer powerful solutions for building iOS apps that integrate with Salesforce. While Forceios provides a quicker, templated approach to app creation, the manual method gives you full control over your project and its configuration.

In modern React development, one of the design patterns that stands out for creating flexible and composable UIs is the Compound Component Pattern. This pattern helps you manage a group of components that are logically related but still need to have distinct, reusable pieces of functionality. In this article, we’ll break down how the Compound Component Pattern is applied in a React Native application by walking through an example of a Card Component with Header, Content, and Footer subcomponents.

What is the Compound Component Pattern?

The Compound Component Pattern is a way to design components that are loosely coupled but still work together as a cohesive whole. Instead of passing a ton of props down the component tree, the parent component manages the shared logic, while the child components focus on their independent concerns.

In this article, we’ll take a look at how the Compound Component Pattern is implemented using a simple Card component structure in React Native.

Let’s dive into the code, which demonstrates how the compound pattern is applied to a Card component.

1. The Card Component: The Parent

const Card: ICardComponent = ({children, style}) => {
  return <View style={[style, styles.card]}>{children}</View>;
};

In this example, the Card component serves as the parent container for the subcomponents. It accepts children as a prop, which means any components passed inside the <Card></Card> wrapper will be rendered here. The style prop allows for customization, and the card itself is styled using styles.card.

Notice that the Card component defines three subcomponents: Header, Content, and Footer. These are nested within the parent Card component, which allows us to compose the final UI in a structured and flexible way.

2. Subcomponents: Header, Content, and Footer

The power of the Compound Pattern comes from how we can define components that can work together, while still maintaining individual behavior. In this case, the Header, Content, and Footer are all defined as separate components but are tightly coupled with the Card.

Card.Header = ({children, style}: IHeader) => {
  return <View style={[style]}>{children}</View>;
};

Card.Content = ({children, style}: IContent) => {
  return <View style={[style]}>{children}</View>;
};

Card.Footer = ({children, style}: IFooter) => {
  return <View style={[style]}>{children}</View>;
};

These components are designed to be used as direct children of the Card component, and each one can accept its own children and style.

• Card.Header can be used to render the header content of the card.
• Card.Content holds the body of the card, where the main content goes.
• Card.Footer provides a footer area, typically for actions or additional details.

3. The App Component: Composing the Card

Now, let’s look at how we can compose these components in the App component.

import React from 'react';
import {StyleSheet, Text, View, ScrollView, SafeAreaView} from 'react-native';
import Switch from './src/componant/switch';
import Card from './src/componant/card';
import {Header} from './src/componant/card/header';
import {Content} from './src/componant/card/content';
import {Footer} from './src/componant/card/footer';

const App = (): React.JSX.Element => {
  return (
    // SafeAreaView to ensure UI is inside the safe area
    <SafeAreaView style={style.container}>
      <ScrollView
        showsVerticalScrollIndicator={false}
        contentContainerStyle={style.root}>
        {/* Card Component with Header, Content, and Footer */}
        <Card>
          <Card.Header>
            <Header />
          </Card.Header>
          <Card.Content>
            <Content />
          </Card.Content>
          <Card.Footer>
            <Footer />
          </Card.Footer>
        </Card>
      </ScrollView>
    </SafeAreaView>
  );
};

export default App;

const style = StyleSheet.create({
  container: {
    flex: 1,
  },
  root: {
    flexGrow: 1,
    alignItems: 'center',
    paddingBottom: 20,
  },
  switchContainer: {
    alignItems: 'center',
    width: '100%',
    paddingTop: 20,
  },
  spacer: {
    height: 20,
  },
});

Here, we’re composing the Card component by passing in the Header, Content, and Footer as its children. Each of these child components is defined separately, but they are now part of the Card structure, thanks to the compound pattern.

Benefits of Using the Compound Pattern

• Readability: The code becomes easier to read because the Card component encapsulates the layout logic, and the child components (Header, Content, Footer) focus only on their content.
• Maintainability: If you need to make changes to the layout or shared logic, you can do so in the parent Card component without modifying each individual child.
• Separation of Concerns: Each component (parent and child) has a clear responsibility, making the codebase easier to manage and extend.

Reusability and Dynamic Composition in the Compound Pattern

One of the key advantages of using the Compound Component Pattern is the flexibility and reusability it brings to your components. In this implementation, each child component — Header, Content, and Footer—is decoupled from the Card component, meaning that you can easily reuse these components in different places across your app, either inside or outside of a Card.

Reusable Child Components

Since the Header, Content, and Footer components are separate and self-contained, you can use them independently throughout your application. For example, you might use the Header component in one part of your app to display a title, and the Footer in another part for actions or information. These components can be used without being wrapped by the Card, allowing for greater flexibility in your UI design.

Dynamic Composition for Greater Flexibility

What’s even more powerful is that the Card component itself can be reused across various parts of your app. You can pass different combinations of Header, Content, and Footer to create unique card layouts as needed. This dynamic composition makes the Card component incredibly versatile and reusable.

For instance, you might create one Card with a custom Header, Content, and Footer for a user profile screen, and another Card with a different Header, Content, and Footer for a product detail page, all by simply passing different content into the same Card wrapper.

Here’s an example:

<Card>
  <Card.Header>
    <Text>User Profile</Text>
  </Card.Header>
  <Card.Content>
    <Text>John Doe</Text>
    <Text>Age: 30</Text>
  </Card.Content>
  <Card.Footer>
    <Button title="Edit Profile" />
  </Card.Footer>
</Card>

Conclusion

The Compound Component Pattern allows for a high degree of flexibility in building reusable components. By decoupling the Header, Content, and Footer from the Card, we can use each of them independently in other parts of the app, or compose them dynamically in different contexts.

This pattern is especially useful when the child components need to be tightly coupled but still remain decoupled from the parent component’s internal logic. With compound components, the parent component manages the state, and the child components consume this state through context or props, resulting in a highly flexible and customizable system.

How Compound Components Work: A Practical Example

In this article I’ll teach you how to write a component using compound component pattern.

Step 1: Define the Parent Component (Switch)

import React, {createContext, useContext, useState} from 'react';
import {View, Text, TouchableOpacity} from 'react-native';
import styles from './styles';

interface ISwitchContext {
  isChecked: boolean;
  toggle: () => void;
}
const SwitchContext = createContext<ISwitchContext | null>(null);

interface ISwitch {
  children: React.ReactNode;
  check?: boolean;
}

interface ISwitchComponent extends React.FC<ISwitch> {
  Label: React.FC<{children: React.ReactNode}>;
  Button: React.FC;
}

const Switch: ISwitchComponent = ({children, check = false}) => {
  const [isChecked, setIsChecked] = useState<boolean>(check);

  const toggle = () => {
    setIsChecked(pre => !pre);
  };

  return (
    <SwitchContext.Provider value={{isChecked, toggle}}>
      <View style={styles.container}>{children}</View>
    </SwitchContext.Provider>
  );
};

Step 2: Define the Child Components (Switch.Label and Switch.Button)

Now, we define the child components, Switch.Label and Switch.Button. These components will consume the state provided by the parent (Switch) via context.

Switch.Label = ({children}: {children: React.ReactNode}) => {
  return <Text style={styles.label}>{children}</Text>;
};

Switch.Button = () => {
  const context = useContext(SwitchContext);

  if (!context) {
    throw new Error('Switch.Button must be used within a Switch component');
  }

  const {isChecked, toggle} = context;

  return (
    <TouchableOpacity style={styles.button} onPress={toggle}>
      <Text style={styles.buttonText}>{isChecked ? 'ON' : 'OFF'}</Text>
    </TouchableOpacity>
  );
};

export default Switch;

Step 3: Use the Compound Components

Now, we can use the Switch component along with its subcomponents (Switch.Label and Switch.Button) in the parent component:

import React from 'react';
import {StyleSheet, View} from 'react-native';
import Switch from './src/componant/switch';

const App = (): React.JSX.Element => {
  return (
    <View style={style.root}>
      <Switch>
        <Switch.Label>Push Notification Enabled</Switch.Label>
        <Switch.Button />
      </Switch>
      <View style={style.spacer} />
      <Switch check={true}>
        <Switch.Label>Enable Dark Mode</Switch.Label>
        <Switch.Button />
      </Switch>
      <View style={style.spacer} />
      <Switch check={true}>
        <Switch.Label>Enable Auto Synce</Switch.Label>
        <Switch.Button />
      </Switch>
    </View>
  );
};

export default App;

const style = StyleSheet.create({
  root: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
  },
  spacer: {
    height: 50,
  },
});

How It Works:

• The Switch component provides the state (isChecked) and the toggle function via SwitchContext.Provider.
• The Switch.Label component simply displays the text passed to it, while the Switch.Button component reads the state from the context and toggles the state when clicked.
• The Switch.Button renders either "ON" or "OFF" based on the isChecked state.

This pattern is extremely flexible because the consumer can customize the rendering of Switch.Label and Switch.Button without worrying about the internal state management or logic.

Conclusion

The compound component pattern in React is a powerful way to build flexible, reusable, and maintainable UIs. By using context and breaking down a component into smaller, composable parts, you can create complex interfaces that are both customizable and easy to manage.

Why Use a Custom API Client?

React native application often require making API requests to fetch data or send updates. Using Axis makes this process easier due to its simplicity and powerful features, such as automatic JSON parsing, built-in request/response interception, and promise-based syntax.However, when your application grows, it’s easy to get stuck with redundant code for every single API call. A custom API client allows you to:

• Centralize logic: Manage headers, authentication, timeouts, and error handling in one place.
• Simplify requests: Abstract HTTP methods (GET, POST, etc.) into reusable functions.
• Improve maintainability: Keep your code DRY and easier to maintain as your app scales.

Step 1: Setting Up the ApiClient Class

To start, let’s create the ApiClient class, which will handle Axios requests. This class will be responsible for managing common configurations like the base URL, headers, and request timeouts.

import axios, { AxiosInstance, AxiosResponse } from 'axios';

export interface ApiPayload<K> {
  payload?: K;
}

class ApiClient {
  private readonly axiosInstance: AxiosInstance;
  private readonly axiosHeaders = {
    Accept: 'application/json',
    'Content-Type': 'application/json',
  };

  constructor() {
    this.axiosInstance = axios.create({
      baseURL: 'https://jsonplaceholder.typicode.com',  // Base URL for JSONPlaceholder (can be replaced)
      headers: this.axiosHeaders,
      timeout: 10000,  // Timeout for requests
      timeoutErrorMessage: 'Slow Network',  // Custom error message for slow requests
      validateStatus(status: number) {
        return (status >= 200 && status < 300) || status === 400 || status === 401;  // Status codes validation
      },
    });
  }

  requestHeader = () => {
    return {
      Authorization: 'Bearer YOUR_TOKEN',  // Authorization token (can be updated dynamically)
    };
  };

  handleBodyResponse = async <K>(response: AxiosResponse): Promise<K> => {
    const { status, data, statusText } = response;
    if (status === 200) return Promise.resolve(data);
    const errorMessage = status === 401 ? 'Unauthorized' : statusText;
    return Promise.reject({ message: errorMessage });
  };

  postApiService = async <K, T>(api: string, reqParam: ApiPayload<K>): Promise<T> => {
    try {
      const response = await this.axiosInstance.post<T>(api, reqParam, {
        headers: { ...this.axiosHeaders, ...this.requestHeader() },
      });
      return this.handleBodyResponse(response);
    } catch (error) {
      console.error('Error in postApiService:', error);
      throw error;
    }
  };

  getApiService = async <K>(api: string): Promise<K> => {
    try {
      const response = await this.axiosInstance.get<K>(api, {
        headers: { ...this.axiosHeaders, ...this.requestHeader() },
      });
      return this.handleBodyResponse(response);
    } catch (error) {
      console.error('Error in getApiService:', error);
      throw error;
    }
  };
}

export const API = new ApiClient();

Step 2: Creating a Flexible Service Handler for API Calls

Next, we need to create a generalized serviceHandler function. This function will manage different HTTP methods (such as GET and POST) and make it easier to interact with the ApiClient.

The goal here is to abstract the repetitive logic and provide a simple interface for making API requests.

import { API, ApiPayload } from './apiClient';

export enum API_METHOD {
  POST = 'POST',
  GET = 'GET',
}

export const serviceHandler = async <K, T>(
  method: API_METHOD,
  url: string,
  payload?: K,
): Promise<T> => {
  try {
    switch (method) {
      case API_METHOD.GET:
        const getResponse = await API.getApiService<T>(url);
        return getResponse;

      case API_METHOD.POST:
        const postResponse = await API.postApiService<K, T>(
          url,
          payload ? { payload } : ({} as ApiPayload<K>),
        );
        return postResponse;

      default:
        throw new Error(`Unsupported HTTP method: ${method}`);
    }
  } catch (error) {
    console.error('Error in serviceHandler:', error);
    throw error;
  }
};

Step 3: Using the serviceHandler for API Calls in React Native

Now that we have both the ApiClient and serviceHandler, making API requests in React Native becomes simple and clean.

Sending Data to an API (POST)

interface CreateUserPayload {
  name: string;
}

const createUser = async (newUser: CreateUserPayload) => {
  try {
    const createdUser = await serviceHandler<CreateUserPayload, User>(
      API_METHOD.POST,
      '/users',
      newUser
    );
    console.log('Created User:', createdUser);
  } catch (error) {
    console.error('Error creating user:', error);
  }
};

Fetching Data from an API (GET)

import { API_METHOD, serviceHandler } from './serviceHandler'; 

// Define the Article interface based on the expected response structure
interface Article {
  id: number;
  title: string;
  content: string;
  author: string;
  publicationDate: string;
}

// Function to get a Medium article by its ID
const getMediumArticle = async (articleId: number): Promise<Article | void> => {
  try {
    const article = await serviceHandler<null, Article>(
      API_METHOD.GET,
      `/articles/${articleId}` 
    );
    console.log('Fetched Article:', article);
    return article;
 } catch (error) {
    console.error('Error fetching article:', error);
  }
};

Conclusion

By leveraging TypeScript’s features like interfaces, generics, and enums, we can ensure that our code is both scalable and easy to maintain, especially as the complexity of the application grows. Whether you’re working with user creation, fetching articles, or any other API interaction, using a consistent service handler pattern simplifies the process, allowing you to focus on building features rather than managing repetitive HTTP logic.

In this article, we will explore how to handle offline synchronization in a React Native app using a flag-based approach similar to how Salesforce handles data sync. By marking client data with specific flags like local, locally_created, locally_updated, and locally_deleted, you can track the state of each record and sync them with the server when network connectivity is restored.

Key Concepts for Offline Synchronization

When an app works offline, data changes need to be stored locally. Once the app regains an internet connection, the app must synchronize this local data with the server. A flagging system is a simple and efficient way to track the state of each record.

Let’s break down the flags you’ll use to track the state of each record:

1. local: The record exists locally, but it hasn’t been modified or created while offline.
2. locally_created: The record was created while offline and needs to be synced with the server.
3. locally_updated: The record has been modified while offline and needs to be synced.
4. locally_deleted: The record was deleted locally, and this deletion should be reflected on the server.

By using these flags, you can ensure that your app knows exactly which records need to be sent to the server when the network is restored.

Setting Up the Data Structure

Let’s start by defining the structure of the client record created locally in the app’s local storage.

Scenario 1: locally_created

{
  client_id: 123,
  local: true,
  locally_created: true,
  locally_updated: false,
  locally_deleted: false,
  last_modified: '2024-11-07T10:00:00Z',
  data: {
    name: "John Doe",
    email: "john.doe@example.com",
    phone: "+1 234 567 890"
  }
}

Explanation :

• locally_created: true: This means that this client record has been newly created while the app was offline. Since the app wasn’t connected to the server at the time of creation, it is marked as locally_created. This record has not yet been synced with the server.
• locally_updated: false: No updates have been made to this client record since it was created.
• locally_deleted: false: No deletion of the client has been performed.
• local: true: Flag indicates that the record is available on the device but hasn’t been sent to the server yet.

Scenario 2: locally_update

{
  client_id: 123,
  local: true,
  locally_created: false,
  locally_updated: true,
  locally_deleted: false,
  last_modified: '2024-11-07T10:30:00Z',
  data: {
    name: "Ron",
    email: "ron@example.com",
    phone: "+1 234 567 891"
  }
}

Explanation :

• locally_created: false: This record was not created locally; it existed previously either on the server or the local database.
• locally_updated: true: This record has been updated while offline (e.g., the client’s name, email, or phone number has been changed). Since the app was offline at the time, this change is marked as locally_updated.
• locally_deleted: false: The record has not been marked for deletion.
• local: true: Flag indicates that the record is available on the device but hasn’t been sent to the server yet.

Scenario 3: locally_deleted

  client_id: 123,
  local: true,
  locally_created: false,
  locally_updated: false,
  locally_deleted: true,
  last_modified: '2024-11-07T10:30:00Z',
  data: {
    name: "Ron",
    email: "ron@example.com",
    phone: "+1 234 567 891"
  }
}

Explanation:

• locally_created: false: This record was not newly created locally; it existed before the offline session (either on the server or in local storage).
• locally_updated: false: No updates have been made to this record locally.
• locally_deleted: true: This record has been marked for deletion locally . This deletion has not yet been reflected on the server, so the record is flagged as locally_deleted.
• local: true: Flag indicates that the record is available on the device but hasn’t been sent to the server yet.

Conflict Resolution

While syncing, conflicts can arise (e.g., when a record was modified both locally and remotely). To handle this, you can implement one of these strategies:

1. Last Write Wins (LWW): Use the last_modified timestamp to determine which version is most recent.
2. Merge Changes: Automatically merge data changes or prompt the user to choose which version to.

Conclusion: Ensuring Seamless User Experience with Offline Sync

In modern mobile applications, offline-first design is crucial for providing users with a smooth and uninterrupted experience, even when network connectivity is unreliable or unavailable. By leveraging flags like local: true, locally_created, locally_updated, and locally_deleted, we can effectively track the state of each record, ensuring that changes made while offline are properly managed and synchronized with the server when the network is restored.

A Generic List Component in React

Let’s look at a practical example of a generic List component that renders a list of items of any type:

import React from 'react';
import { View } from 'react-native';
import { FooterView, ProtocolItem } from '~components/molecules';
import styles from './styles';
import Layout from '../Layout';

interface ListItem {
  id: number;
  name: string;
  isChecked: boolean;
}

interface ListProps<T extends ListItem> {
  items: T[];
  renderItem: (item: T) => React.ReactNode;
  handleItemClick: (item: T) => void;
}

const List = <T extends ListItem>({ items, renderItem, handleItemClick }: ListProps<T>) => {
  const renderListItems = () => {
    return items.map((item) => (
      <ProtocolItem
        key={item.id}
        Name={item.name}
        isChecked={item.isChecked}
        onItemClick={() => handleItemClick(item)} // Pass the correct item on click
      />
    ));
  };

  return (
    <Layout stickyHeaderIndices={[0]}>
      <View style={styles.container}>
        <View style={styles.checklistContainer}>
          {renderListItems()}
        </View>
      </View>
    </Layout>
  );
};

export default List;

Key Points:

• The List component is a generic component that works with any type that extends ListItem.
• We use generics to type the list of items (items: T[]) and the handleItemClick function.
• The renderItem function allows you to render the items in a custom way, while keeping the component flexible and reusable for different types.

By using generics in this List component, you ensure that it is type-safe and flexible enough to be used with different types of list items.

What Are Generics?

Generics in TypeScript allow you to create functions, classes, and interfaces that work with any data type while maintaining full type safety. The benefit of generics is that they provide reusability and flexibility without losing the power of TypeScript’s static typing system.

Basic Syntax of Generics

The basic syntax for defining a generic function in TypeScript looks like this:

function logValue<T>(arg: T): T {
  return arg;
}

Here:

• T is a placeholder for any type that will be determined at runtime.
• T can be any valid TypeScript type (string, number, boolean, custom interfaces, etc.).
• The function logValue takes an argument arg of type T, and returns a value of type T.

Generics with Arrays

Generics are particularly useful when working with arrays, collections, or lists of data, allowing you to maintain type safety when you don’t know the specific type in advance.

Example 1: Reversing an Array with Generics

function reverse<T>(arr: T[]): T[] {
  return arr.reverse();
}

const reversedNumbers = reverse([1, 2, 3, 4]);  // Inferred type: number[]
const reversedStrings = reverse(["apple", "banana", "cherry"]);  // Inferred type: string[]

console.log(reversedNumbers);  // Outputs: [4, 3, 2, 1]
console.log(reversedStrings);  // Outputs: ["cherry", "banana", "apple"]

Here, the function reverse takes an array of type T[] and returns an array of the same type. This ensures that even though the array can contain different types of data, it will always be type-safe.

Generics with Interfaces

You can also use generics in interfaces to define flexible structures. This allows you to define reusable, type-safe data structures.

Example 2: Using Generics in an Interface

interface Box<T> {
  value: T;
}

const numberBox: Box<number> = { value: 42 };
const stringBox: Box<string> = { value: "Hello World" };

console.log(numberBox.value); // Outputs: 42
console.log(stringBox.value); // Outputs: Hello World

Example 3: Using Generics in API Responses

interface Response<T> {
  status: string;
  data: T;
}

function doWebRequest<T>(url: string, callback: (result: Response<T>) => void): void {
  const result: Response<T> = {
    status: "success",
    data: {} as T,
  };
  callback(result);
}

doApiRequest<number>("https://api.example.com/number", (result) => {
  console.log(result.data + 5);  
});

doApiRequest<string>("https://api.example.com/string", (result) => {
  console.log(result.data.toUpperCase());  
});

In this example:

• The Response interface is a generic interface that can hold data of any type.
• The doWebRequest function accepts a URL and a callback that expects a Response<T>, where T can be any type.

By using generics, we ensure type safety, so we don’t have to worry about accidentally trying to add 5 to a string or calling .toUpperCase() on a number.

Conclusion

Generics in TypeScript offer a robust way to write flexible and reusable code while maintaining strong type safety.

Mastering Generics in TypeScript: A Complete Guide was originally published in CodeX on Medium, where people are continuing the conversation by highlighting and responding to this story.