Forem: Rushikesh Pandit

Handling Sensitive UI Data in React Native: Practical Approaches Across iOS and Android

Rushikesh Pandit — Tue, 31 Mar 2026 10:06:41 +0000

Handling Sensitive UI Data in React Native

Introduction

As mobile applications increasingly deal with sensitive user data—financial details, personal health information, authentication flows—UI-level privacy becomes a non-trivial concern.

While backend security is well understood, protecting what’s visible on the screen is often overlooked.

The Core Problem

Each platform handles screen privacy differently:

Android

Uses FLAG_SECURE to block screenshots and recordings
Requires ContentObserver to detect screenshots

iOS

No direct API to block screenshots
Relies on UITextField (isSecureTextEntry) behavior

Key Areas to Address

1. Screen Capture Protection

Android provides native support. iOS requires workaround techniques.

2. App Switcher Snapshots

Apps must hide sensitive data before going to background.

3. Screenshot Detection

Detection is possible, prevention is limited.

4. Clipboard Management

Sensitive data should be cleared proactively.

5. Copy/Paste Restrictions

Needs native-level interception.

Architectural Approach

A scalable approach includes:

Hooks for declarative usage
Imperative APIs for lifecycle control
View wrappers for sensitive UI

Trade-offs

iOS limitations on screenshot blocking
Android emulator bypasses
UX vs security balance

Conclusion

UI privacy is a cross-platform engineering problem requiring thoughtful abstraction and careful handling of OS differences.

If you're building anything in fintech, banking, or enterprise on React Native and want a lightweight security layer without pulling in a large SDK — give it a try.
Feedback welcome, especially if you hit false positives on specific devices.

Built with Swift, Kotlin, and C++. No external dependencies.

Links:

npm Package
GitHub Repository
Full Documentation
Issue Tracker

Found this helpful? Drop a ❤️ on the article and ⭐ on GitHub!
Questions or suggestions? Drop them in the comments below!

Feel free to reach out to me if you have any questions or need assistance.
LinkedIn: https://www.linkedin.com/in/rushikesh-pandit-646834100/
GitHub: https://github.com/rushikeshpandit
Portfolio: https://www.rushikeshpandit.in

#ReactNative #TypeScript #MobileDevelopment #SoftwareEngineering #DevCommunity #root-detection #jailbreak-detection #mobile-security
#device-integrity

Detecting Rooted & Jailbroken Devices in React Native — How I Built It and What I Learned

Rushikesh Pandit — Sun, 08 Mar 2026 06:08:32 +0000

I've been working on a React Native security library for the past few months. Not because there wasn't anything out there, but because most existing solutions were either outdated, not maintained, or didn't support the New Architecture.

So I built react-native-root-jail-detect from scratch — native Swift for iOS, Kotlin + C++ for Android, full TurboModules and Fabric support.
Here's what I learned building it.

The Problem With Simple File Checks

Most jailbreak detection libraries do something like this:

let jailbreakPaths = ["/Applications/Cydia.app", "/bin/bash"]
return jailbreakPaths.contains { FileManager.default.fileExists(atPath: $0) }

This works — until it doesn't. /bin/sh exists on stock iOS. /var/log/syslog exists on non-jailbroken devices. And on the simulator, the entire macOS filesystem is exposed, so paths like /usr/bin/ssh and /etc/ssh/sshd_config all exist on a perfectly clean machine.

The fix isn't just a better list of paths. It's knowing which paths are safe to check, where, and when.
For the simulator I gate real-device-only checks behind:

#if targetEnvironment(simulator)
return false
#else
// actual checks
#endif

And paths like /bin/bash only go into a realDeviceOnlyPaths list that never runs on simulator.

Debugger Detection Is Trickier Than It Looks

There are four common approaches:

sysctl P_TRACED — most reliable

var info = kinfo_proc()
var size = MemoryLayout<kinfo_proc>.size
var name: [Int32] = [CTL_KERN, KERN_PROC, KERN_PROC_PID, getpid()]
let ret = sysctl(&name, 4, &info, &size, nil, 0)
guard ret == 0 else { return false }
return (info.kp_proc.p_flag & P_TRACED) != 0

Mach exception ports — catches LLDB specifically

// If EXC_MASK_BREAKPOINT has a valid port registered,
// something is listening for breakpoints
let result = task_get_exception_ports(
    mach_task_self_,
    exception_mask_t(EXC_MASK_BREAKPOINT),
    masks, &count, ports, behaviors, flavors
)
// Validate ports are not MACH_PORT_NULL — avoids false positives

ptrace TRACEME

if ptrace(PT_TRACE_ME, 0, nil, 0) == -1 {
    return errno == EPERM  // already being traced
}
ptrace(PT_DETACH, 0, nil, 0)
return false

TracerPid on Android

File("/proc/self/status").forEachLine { line ->
    if (line.startsWith("TracerPid:")) {
        return line.substringAfter(":").trim().toInt() > 0
    }
}

The gotcha I hit: when you run your app via Xcode on a real device, Xcode automatically attaches LLDB. No breakpoints needed — just running from Xcode is enough to trigger all three iOS checks. The fix is gating these behind #if DEBUG or a custom build flag like SECURITY_CHECKS_ENABLED that you only set on Release and Staging schemes.

Frida Detection

Frida is the main tool attackers use to hook into running apps and bypass security checks. Detecting it has a few layers:

Loaded image scan:

for i in 0..<_dyld_image_count() {
    let name = String(cString: _dyld_get_image_name(i)).lowercased()
    if name.contains("frida") || name.contains("gum-js") {
        return true
    }
}

Symbol lookup:

let suspiciousSymbols = ["gum_js_loop", "frida_agent_main", "gum_script_backend_create"]
for sym in suspiciousSymbols {
    if dlsym(UnsafeMutableRawPointer(bitPattern: -2), sym) != nil {
        return true
    }
}

On Android — memory map scan:

std::ifstream maps("/proc/self/maps");
std::string line;
while (std::getline(maps, line)) {
    if (line.find("frida") != std::string::npos ||
        line.find("gum-js") != std::string::npos) {
        return true;
    }
}

These only catch unobfuscated Frida. A determined attacker can rename the agent. But most script-kiddie level attacks use default Frida, and this catches those reliably.

The Runtime Watchdog

This was the most interesting part to build. File path checks and debugger checks at launch are good, but they miss a common attack pattern:

App launches — device looks clean
Attacker attaches Frida or LLDB after launch
App never re-checks — attacker is in

The watchdog solves this by running checks continuously on a background thread with randomized timing (±40% jitter to make it harder to predict and bypass):

private static func randomDelay(base: TimeInterval) -> TimeInterval {
    let jitter = base * 0.4
    return base + TimeInterval.random(in: -jitter...jitter)
}

It also checks for timing gaps — if the loop stalls for more than interval * 4, it's a signal that the process was paused (e.g. by a debugger hitting a breakpoint):

if now - lastRun > interval * 4 {
    handleThreat(detector: detector)
}

Three response modes depending on how aggressive you want to be:

enum ProtectionMode {
    case logOnly       // log and continue
    case throwException // crash with reason
    case terminate     // kill(getpid(), SIGKILL)
}

For most apps I'd recommend logOnly in staging and terminate in production.

Method Swizzling Detection — What Didn't Work
My first approach was checking if UIViewController.viewDidLoad's IMP pointed back to UIKit:

// ❌ This doesn't work
let imagePath = String(cString: fname).lowercased()
return !imagePath.contains("uikit")

Problem: viewDidLoad is a Swift method. Its IMP can point to a Swift-to-ObjC thunk or a dispatch stub — neither resolves to a UIKit path via dladdr. Every app that overrides viewDidLoad would trigger this.
The fix is checking pure ObjC methods with stable, well-known IMPs instead:

// ✅ This works
let checks: [(AnyClass, Selector, String)] = [
    (NSObject.self, #selector(NSObject.description), "libobjc"),
    (NSObject.self, NSSelectorFromString("respondsToSelector:"), "libobjc"),
    (NSArray.self,  #selector(getter: NSArray.count), "corefounda"),
]
// Verify each IMP resolves back to its expected binary via dladdr

Usage

npm install react-native-root-jail-detect

import RootJailDetect, { SecurityWatchdog, ProtectionMode } from 'react-native-root-jail-detect';

// One-shot check
const isCompromised = await RootJailDetect.isDeviceRooted();
const reasons = await RootJailDetect.getDetectionReasons();

// Continuous monitoring
SecurityWatchdog.start({
  intervalMs: 3000,
  mode: ProtectionMode.TERMINATE,
});

// Stop monitoring
SecurityWatchdog.stop();

What's Next

Certificate pinning integration
Integrity check for the JS bundle itself
Anti-tampering for the native binary

Built with Swift, Kotlin, and C++. No external dependencies.

Links:

npm Package
GitHub Repository
Full Documentation
Issue Tracker

Found this helpful? Drop a ❤️ on the article and ⭐ on GitHub!
Questions or suggestions? Drop them in the comments below!

#ReactNative #TypeScript #MobileDevelopment #SoftwareEngineering #DevCommunity #root-detection #jailbreak-detection #mobile-security
#device-integrity

Published a Lightweight Library for Root/Jailbreak Detection React Native

Rushikesh Pandit — Sun, 22 Feb 2026 12:55:02 +0000

react-native-root-jail-detect

Security is first thing in mobile app development, especially for banking, fintech, and enterprise applications. One critical security measure is detecting whether a device has been rooted (Android) or jailbroken (iOS). These compromised devices can expose your app to security vulnerabilities, data breaches, and unauthorized access.

Today, I'm excited to share react-native-root-jail-detect - a lightweight, open-source library that makes device security checks incredibly simple.

Why Another Root/Jailbreak Detection Library?

When building security-focused React Native apps, I noticed most existing solutions were either:

Too heavy (bloating app size)
Performance-intensive
Closed-source or poorly maintained
Complex APIs requiring extensive setup

I wanted something different: simple, fast, tiny, and open source forever.

What Makes This Special?

Incredibly Lightweight (~60KB)

In a world where every kilobyte matters for app store optimization and user experience, this library weighs in at just ~60KB. That's smaller than most image assets in your app!

# Installation is a breeze
npm install react-native-root-jail-detect

Clean & Simple API

Forget complex configurations. One method, one promise, one boolean result:

import RootJailDetect from 'react-native-root-jail-detect';

const isCompromised = await RootJailDetect.isDeviceRooted();

if (isCompromised) {
  // Handle accordingly - restrict features, show warning, etc.
}

That's it. No configuration files, no initialization, no complex setup.

New Architecture Ready

Built from the ground up to support React Native's new architecture (Fabric and TurboModules). Future-proof your security implementation today.

Battle-Tested Detection Methods

The library doesn't rely on a single detection method. Instead, it employs multiple techniques:

For Android (Root Detection):

Binary file scanning (su, Superuser.apk, etc.)
Runtime command execution attempts
Multiple common root path checks

For iOS (Jailbreak Detection):

Cydia and jailbreak app detection
Restricted file system access attempts
Sandbox integrity verification

Real-World Usage Example

Here's how you might integrate it into a banking app:

import React, { useEffect, useState } from 'react';
import { Alert } from 'react-native';
import RootJailDetect from 'react-native-root-jail-detect';

const BankingApp = () => {
  const [securityPassed, setSecurityPassed] = useState(false);

  useEffect(() => {
    performSecurityCheck();
  }, []);

  const performSecurityCheck = async () => {
    try {
      const isRooted = await RootJailDetect.isDeviceRooted();

      if (isRooted) {
        Alert.alert(
          'Security Alert',
          'Your device appears to be rooted/jailbroken. ' +
          'For your security, some features will be restricted.',
          [
            { text: 'Learn More', onPress: () => openSecurityInfo() },
            { text: 'OK', style: 'cancel' }
          ]
        );
        setSecurityPassed(false);
      } else {
        setSecurityPassed(true);
      }
    } catch (error) {
      console.error('Security check failed:', error);
      // Handle gracefully - perhaps allow access but log the incident
      setSecurityPassed(true);
    }
  };

  if (!securityPassed) {
    return <RestrictedModeUI />;
  }

  return <FullBankingFeatures />;
};

Perfect Use Cases

This library shines in applications requiring enhanced security:

Banking & Fintech Apps:
- Protect transaction integrity
- Comply with financial regulations
- Prevent unauthorized access to accounts
Enterprise Applications
- Enforce corporate security policies
- MDM compliance
- Protect confidential business data
Healthcare Apps
- HIPAA compliance requirements
- Patient data protection
- Secure telehealth platforms
Gaming Apps
- Prevent cheating
- Protect in-app purchases
- Maintain fair gameplay
E-commerce & Payment Apps
- PCI-DSS compliance
- Secure payment processing
- Fraud prevention

Important Considerations

While this library is highly effective, it's important to understand its limitations:

Not 100% Foolproof: Sophisticated concealment tools exist (RootCloak, Liberty, etc.)
Part of Defense-in-Depth: Use alongside SSL pinning, code obfuscation, and server-side validation
User Experience Matters: Don't alienate legitimate users with heavy-handed restrictions
Keep Updated: Root/jailbreak methods evolve; regular updates are crucial

Best Practices for Implementation

Graceful Degradation

Don't immediately lock users out. Consider a tiered approach:

const handleRootedDevice = async () => {
  const isRooted = await RootJailDetect.isDeviceRooted();

  if (isRooted) {
    // Tier 1: Show warning, allow basic features
    showSecurityWarning();

    // Tier 2: Disable sensitive features
    disableBiometricAuth();
    disableStoredPaymentMethods();

    // Tier 3: Require additional verification
    requireTwoFactorAuth();

    // Analytics: Log for fraud detection
    logSecurityEvent('rooted_device_detected');
  }
};

Combine with Other Security Measures

const comprehensiveSecurityCheck = async () => {
  const checks = await Promise.all([
    RootJailDetect.isDeviceRooted(),
    checkSSLPinning(),
    validateAppIntegrity(),
    verifyDebuggerAbsence()
  ]);

  return checks.every(check => check === true);
};

Server-Side Validation

Never rely solely on client-side checks:

const authenticateWithSecurityCheck = async (credentials) => {
  const isRooted = await RootJailDetect.isDeviceRooted();

  // Send security status to backend
  const response = await fetch('/api/auth', {
    method: 'POST',
    body: JSON.stringify({
      ...credentials,
      deviceSecurity: {
        isRooted,
        deviceId: getDeviceId(),
        appIntegrity: getAppSignature()
      }
    })
  });

  // Server makes final decision on access
  return response.json();
};

Open Source Forever

This project is and will always remain 100% open source under the MIT license. Why?

Transparency: Security through obscurity doesn't work
Community: Better detection methods emerge from collaborative effort
Trust: You can audit every line of code
Innovation: Fork it, modify it, contribute back

Every contribution, no matter how small, makes a difference!

Get Started Today

# Install
npm install react-native-root-jail-detect

# iOS
cd ios && pod install && cd ..

# Use
import RootJailDetect from 'react-native-root-jail-detect';
const isRooted = await RootJailDetect.isDeviceRooted();

Building secure mobile apps doesn't have to be complicated or expensive. With react-native-root-jail-detect, you get enterprise-grade security detection in a package smaller than a thumbnail image.

Whether you're building the next fintech unicorn or a simple app that handles sensitive data, this library provides the peace of mind that comes with knowing your users' device integrity.

Give it a try, star the repo, and join me in making React Native apps more secure for everyone!

Links:

npm Package
GitHub Repository
Full Documentation
Issue Tracker

Found this helpful? Drop a ❤️ on the article and ⭐ on GitHub!
Questions or suggestions? Drop them in the comments below!

#ReactNative #TypeScript #MobileDevelopment #SoftwareEngineering #DevCommunity #root-detection #jailbreak-detection #mobile-security
#device-integrity

Mastering React Native with TypeScript: From Basics to Brilliance - Part 3

Rushikesh Pandit — Sat, 02 Aug 2025 15:03:53 +0000

React Native has come a long way, and with the latest versions offering improved performance and TypeScript-first development, it’s a great time to dive into building robust apps with navigation and API communication in mind.
In this article, we’ll explore:

Setting up React Navigation in a TypeScript project
Working with Stacks and Tabs
Managing API calls with axios and useEffect
Handling loading, error, and data states
Bonus: Tips for organizing your codebase!

Prerequisites

Node.js 18+
React Native CLI or Expo (we'll go with bare React Native here)
React Native 0.76+
TypeScript
Basic understanding of React Native components

Setup React Navigation

First, install the required dependencies:

npm install @react-navigation/native
npm install react-native-screens react-native-safe-area-context react-native-gesture-handler react-native-reanimated
npx pod-install

Then install the stack and bottom tab navigators:

npm install @react-navigation/native-stack @react-navigation/bottom-tabs

Update babel.config.js for reanimated (if not Expo):

module.exports = {
  presets: ['module:metro-react-native-babel-preset'],
  plugins: ['react-native-reanimated/plugin'],
};

Create Navigation Structure

navigation/RootNavigator.tsx

import React from 'react';
import { NavigationContainer } from '@react-navigation/native';
import { createNativeStackNavigator } from '@react-navigation/native-stack';
import HomeScreen from '../screens/HomeScreen';
import DetailsScreen from '../screens/DetailsScreen';

export type RootStackParamList = {
  Home: undefined;
  Details: { userId: number };
};

const Stack = createNativeStackNavigator<RootStackParamList>();

const RootNavigator = () => (
  <NavigationContainer>
    <Stack.Navigator initialRouteName="Home">
      <Stack.Screen name="Home" component={HomeScreen} />
      <Stack.Screen name="Details" component={DetailsScreen} />
    </Stack.Navigator>
  </NavigationContainer>
);

export default RootNavigator;

Create Screen Components for Home Screen

screens/HomeScreen.tsx

import React, { useEffect, useState } from 'react';
import { View, Text, Button, FlatList, ActivityIndicator } from 'react-native';
import axios from 'axios';
import { NativeStackScreenProps } from '@react-navigation/native-stack';
import { RootStackParamList } from '../navigation/RootNavigator';

type Props = NativeStackScreenProps<RootStackParamList, 'Home'>;

interface User {
  id: number;
  name: string;
}

const HomeScreen: React.FC<Props> = ({ navigation }) => {
  const [users, setUsers] = useState<User[]>([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    axios.get<User[]>('https://jsonplaceholder.typicode.com/users')
      .then(response => setUsers(response.data))
      .catch(err => setError(err.message))
      .finally(() => setLoading(false));
  }, []);

  if (loading) return <ActivityIndicator />;
  if (error) return <Text>Error: {error}</Text>;

  return (
    <FlatList
      data={users}
      keyExtractor={item => item.id.toString()}
      renderItem={({ item }) => (
        <View style={{ padding: 10 }}>
          <Text>{item.name}</Text>
          <Button
            title="View Details"
            onPress={() => navigation.navigate('Details', { userId: item.id })}
          />
        </View>
      )}
    />
  );
};

export default HomeScreen;

Create Screen Components for Detail Screen

screens/DetailsScreen.tsx

import React, { useEffect, useState } from 'react';
import { View, Text, ActivityIndicator } from 'react-native';
import { NativeStackScreenProps } from '@react-navigation/native-stack';
import axios from 'axios';
import { RootStackParamList } from '../navigation/RootNavigator';

type Props = NativeStackScreenProps<RootStackParamList, 'Details'>;

interface UserDetail {
  id: number;
  name: string;
  email: string;
  phone: string;
}

const DetailsScreen: React.FC<Props> = ({ route }) => {
  const { userId } = route.params;
  const [user, setUser] = useState<UserDetail | null>(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    axios.get<UserDetail>(`https://jsonplaceholder.typicode.com/users/${userId}`)
      .then(response => setUser(response.data))
      .finally(() => setLoading(false));
  }, [userId]);

  if (loading) return <ActivityIndicator />;
  if (!user) return <Text>No user found</Text>;

  return (
    <View style={{ padding: 20 }}>
      <Text style={{ fontSize: 18 }}>{user.name}</Text>
      <Text>{user.email}</Text>
      <Text>{user.phone}</Text>
    </View>
  );
};

export default DetailsScreen;

Organize API Layer (Optional but Recommended)

Create a file api/client.ts:

import axios from 'axios';

const client = axios.create({
  baseURL: 'https://jsonplaceholder.typicode.com/',
  timeout: 5000,
});

export default client;

Then import and use client.get() instead of axios.get().

Project Structure Suggestion

/src
  /navigation
    RootNavigator.tsx
  /screens
    HomeScreen.tsx
    DetailsScreen.tsx
  /api
    client.ts
  /types
    index.ts
App.tsx

Final Thoughts

React Navigation’s TypeScript support makes route safety a breeze.
Centralizing API calls helps scale and debug faster.
Handling loading/error/data states improves user experience.
Organize your folders early—it pays off later!

That's it for today. In the next part of this series, we’ll explore advanced topics like redux toolkit and it's implementation.

#ReactNative #TypeScript #MobileDevelopment #SoftwareEngineering #DevCommunity

Mastering React Native with TypeScript: From Basics to Brilliance - Part 2

Rushikesh Pandit — Sat, 26 Jul 2025 07:21:13 +0000

React Native hooks provide an intuitive way to manage state and side effects in your components. Introduced in React 16.8, hooks allow us to use state and other React features without writing class components, making functional components powerful and more readable.

In this article, we will explore the most commonly used hooks, how they work, and how you can leverage them in your React Native projects. We’ll also look at how to create custom hooks.

Why Hooks?

Hooks are functions that let you “hook into” React state and lifecycle features from function components. They make your code cleaner, easier to understand, and reusable.

`useState`

useState is one of the most commonly used hooks. It lets you add state to functional components. With useState, you can create variables that store component-level data and re-render your component whenever that data changes.

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

const Counter = () => {
  const [count, setCount] = useState<number>(0);

  return (
    <View>
      <Text>Count: {count}</Text>
      <Button title="Increase" onPress={() => setCount(count + 1)} />
    </View>
  );
};

export default Counter;

How it works:

useState takes the initial value (0 in the example) and returns an array containing the current value (count) and a function to update it (setCount).

`useEffect`

useEffect is used to perform side effects in function components. It runs after every render by default but can also be customized to run only when specific values change.

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

const DataFetcher = () => {
  const [data, setData] = useState<string | null>(null);

  useEffect(() => {
    // Simulate fetching data from an API
    const fetchData = async () => {
      const result = await new Promise((resolve) => 
        setTimeout(() => resolve("Fetched Data"), 2000)
      );
      setData(result as string);
    };

    fetchData();
  }, []); // empty array ensures this runs once when the component mounts

  return <View>{data ? <Text>{data}</Text> : <Text>Loading...</Text>}</View>;
};

export default DataFetcher;

How it works:

useEffect runs after the component renders. In this case, we simulate fetching data, and the effect only runs once because of the empty dependency array [].

`useContext`

useContext allows you to use values from React's Context API. This is helpful for passing data like theme or authentication information without prop drilling.

import React, { createContext, useContext } from 'react';
import { Text, View } from 'react-native';

// Create a context
const ThemeContext = createContext('light');

const ThemedComponent = () => {
  const theme = useContext(ThemeContext);
  return <Text>Current Theme: {theme}</Text>;
};

const App = () => (
  <ThemeContext.Provider value="dark">
    <View>
      <ThemedComponent />
    </View>
  </ThemeContext.Provider>
);

export default App;

How it works:

useContext allows you to consume the value of the nearest ThemeContext.Provider, eliminating the need to pass down props manually.

`useReducer`

useReducer is similar to useState but is used for more complex state logic. It is often used when the state has multiple transitions.

import React, { useReducer } from 'react';
import { Text, Button, View } from 'react-native';

type Action = { type: 'increment' | 'decrement' };
const reducer = (state: number, action: Action) => {
  switch (action.type) {
    case 'increment':
      return state + 1;
    case 'decrement':
      return state - 1;
    default:
      return state;
  }
};

const Counter = () => {
  const [count, dispatch] = useReducer(reducer, 0);

  return (
    <View>
      <Text>Count: {count}</Text>
      <Button title="Increase" onPress={() => dispatch({ type: 'increment' })} />
      <Button title="Decrease" onPress={() => dispatch({ type: 'decrement' })} />
    </View>
  );
};

export default Counter;

How it works:

useReducer takes a reducer function and an initial state, returning the current state and a dispatch function to trigger state changes.

`useCallback`

useCallback is used to memoize functions so they aren’t recreated on every render, which can be useful for optimization in child components.

import React, { useState, useCallback } from 'react';
import { Text, Button, View } from 'react-native';

const ChildComponent = React.memo(({ onClick }: { onClick: () => void }) => (
  <Button title="Click me" onPress={onClick} />
));

const ParentComponent = () => {
  const [count, setCount] = useState(0);

  const increment = useCallback(() => {
    setCount((prev) => prev + 1);
  }, []); // Function is memoized, won't recreate unless dependencies change

  return (
    <View>
      <Text>Count: {count}</Text>
      <ChildComponent onClick={increment} />
    </View>
  );
};

export default ParentComponent;

How it works:

useCallback returns a memoized version of the increment function, ensuring it is not recreated unless dependencies change.

`useMemo`

useMemo is used to memoize values instead of functions. It recalculates the value only when dependencies change, improving performance in expensive calculations.

import React, { useMemo, useState } from 'react';
import { Text, Button, View } from 'react-native';

const ExpensiveComponent = () => {
  const [count, setCount] = useState(0);

  const expensiveCalculation = useMemo(() => {
    // Simulate an expensive computation
    return count * 1000;
  }, [count]);

  return (
    <View>
      <Text>Result: {expensiveCalculation}</Text>
      <Button title="Increase Count" onPress={() => setCount(count + 1)} />
    </View>
  );
};

export default ExpensiveComponent;

How it works:

useMemo ensures the expensive calculation runs only when count changes.

`useRef`

useRef is used to persist values across renders without causing a re-render. It’s often used to reference DOM elements or hold mutable values.

import React, { useRef } from 'react';
import { Button, TextInput, View } from 'react-native';

const InputFocus = () => {
  const inputRef = useRef<TextInput | null>(null);

  const focusInput = () => {
    inputRef.current?.focus();
  };

  return (
    <View>
      <TextInput ref={inputRef} style={{ height: 40, borderColor: 'gray', borderWidth: 1 }} />
      <Button title="Focus Input" onPress={focusInput} />
    </View>
  );
};

export default InputFocus;

How it works:

useRef creates a reference to the TextInput component, allowing us to programmatically control its focus.

`useLayoutEffect`

useLayoutEffect works similarly to useEffect but is fired synchronously after all DOM mutations, ensuring your effect runs before the browser paints.

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

const LayoutEffectComponent = () => {
  const [layout, setLayout] = useState({ width: 0, height: 0 });

  useLayoutEffect(() => {
    // This effect runs before the browser updates the screen
    setLayout({ width: 100, height: 100 });
  }, []);

  return (
    <View style={{ width: layout.width, height: layout.height }}>
      <Text>Layout size: {layout.width} x {layout.height}</Text>
    </View>
  );
};

export default LayoutEffectComponent;

How it works:

useLayoutEffect is useful for reading layout measurements and synchronizing DOM mutations.

Creating Custom Hooks

Custom hooks allow you to extract and reuse logic from components. They are simply functions that use hooks internally.

import { useState, useEffect } from 'react';

const useFetchData = (url: string) => {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const fetchData = async () => {
      const response = await fetch(url);
      const result = await response.json();
      setData(result);
      setLoading(false);
    };
    fetchData();
  }, [url]);

  return { data, loading };
};

export default useFetchData;

You can now use useFetchData in any component to fetch data.

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

const DataComponent = () => {
  const { data, loading } = useFetchData('https://jsonplaceholder.typicode.com/todos/1');

  return (
    <View>{loading ? <Text>Loading...</Text> : <Text>{JSON.stringify(data)}</Text>}</View>
  );
};

export default DataComponent;

React hooks, combined with TypeScript, offer a powerful and concise way to manage state and side effects in your React Native apps. By mastering hooks like useState, useEffect, and others, you can write cleaner, more efficient components. Additionally, creating custom hooks allows you to reuse logic across your application.

That's it for today. In the next part of this series, we’ll explore advanced topics like navigation, animations, and working with APIs.

#ReactNative #TypeScript #MobileDevelopment #SoftwareEngineering #DevCommunity

Mastering React Native with TypeScript: From Basics to Brilliance - Part 1

Rushikesh Pandit — Thu, 09 Jan 2025 14:37:05 +0000

Are you ready to dive into the world of mobile app development without mastering two separate languages for iOS and Android? Meet React Native—the game-changing framework from Facebook that lets you build high-performance, cross-platform apps using the language you already love: JavaScript (and in our case, TypeScript)!

With React Native, you can build apps that look, feel, and perform as a true native app would. No wonder it's powering industry-leading apps like Instagram, Airbnb, and Tesla.

Kickstarting your journey into the world of React Native 0.76 with TypeScript, we are going to go over what the core building blocks of any application are. Whether you're a curious beginner or an experienced developer seeking to hone your abilities in TypeScript, this guide will get you moving toward mobile development greatness.

We're covering everything you need to know to build your first app:

The Core Components include View, Text, and ScrollView
Styling techniques that make your UI pop
Managing Props and State for dynamic interactions
Mastering lists with FlatList for seamless data handling

By the end of this series, you’ll not only understand the foundation of React Native but also have practical, real-world code snippets to kickstart your app development journey. Let’s make your dream app a reality—starting now!!

Core Components in React Native

Core components are the basic building blocks of every React Native application. They connect the JavaScript world with the native world, and that is where you get the building blocks to craft amazing user interfaces. Let's take a look at each of them.

1 . View

The View component is the fundamental container in React Native. It’s used to group and layout other components. Think of it as a div in web development.

Example: Creating a Centered Box

import React from 'react';
import { View, StyleSheet } from 'react-native';

const App = () => (
  <View style={styles.container}>
    <View style={styles.box} />
  </View>
);

const styles = StyleSheet.create({
  container: { flex: 1, justifyContent: 'center', alignItems: 'center' },
  box: { width: 100, height: 100, backgroundColor: 'blue' },
});

export default App;

Here, we use flex: 1 to ensure the View fills the entire screen, and justifyContent and alignItems center the box.

2 . Text

The Text component is used for rendering text on the screen. It supports various text styles and nested elements.

Example: Displaying Styled Text

import React from 'react';
import { Text, StyleSheet } from 'react-native';

const App = () => (
  <Text style={styles.text}>Hello, React Native with TypeScript!</Text>
);

const styles = StyleSheet.create({
  text: { fontSize: 20, color: 'purple', textAlign: 'center', marginTop: 20 },
});

export default App;

Notice how we use fontSize, color, and textAlign to style the Text component.

3 . Image

The Image component is used to display images. It supports both local and remote image sources.

Example: Displaying a Remote Image

import React from 'react';
import { Image, StyleSheet } from 'react-native';

const App = () => (
  <Image
    source={{ uri: 'https://reactnative.dev/img/tiny_logo.png' }}
    style={styles.image}
  />
);

const styles = StyleSheet.create({
  image: { width: 100, height: 100, borderRadius: 10 },
});

export default App;

The borderRadius property gives the image rounded corners.

4 . TextInput

The TextInput component captures user input. It supports properties like placeholder, onChangeText, and value.

Example: Handling User Input

import React, { useState } from 'react';
import { TextInput, StyleSheet, View, Text } from 'react-native';

const App = () => {
  const [input, setInput] = useState<string>('');

  return (
    <View style={styles.container}>
      <TextInput
        style={styles.input}
        placeholder="Type here..."
        value={input}
        onChangeText={setInput}
      />
      <Text>You typed: {input}</Text>
    </View>
  );
};

const styles = StyleSheet.create({
  container: { padding: 20 },
  input: { borderWidth: 1, borderColor: '#ccc', padding: 10, borderRadius: 5, marginBottom: 10 },
});

export default App;

The onChangeText handler updates the state with the user’s input.

5 . TouchableOpacity

The TouchableOpacity component enables touch interactions with a fading effect.

Example: Creating a Button

import React from 'react';
import { TouchableOpacity, Text, StyleSheet } from 'react-native';

const App = () => (
  <TouchableOpacity style={styles.button} onPress={() => alert('Button Pressed!')}>
    <Text style={styles.text}>Press Me</Text>
  </TouchableOpacity>
);

const styles = StyleSheet.create({
  button: { backgroundColor: 'blue', padding: 10, borderRadius: 5 },
  text: { color: 'white', textAlign: 'center' },
});

export default App;

The onPress handler triggers an action when the button is tapped.

6 . ScrollView

The ScrollView component allows for scrollable content. It’s ideal for layouts with a small amount of content that won’t require heavy performance optimization.

Example: Rendering a Scrollable List

import React from 'react';
import { ScrollView, Text, StyleSheet } from 'react-native';

const App = () => (
  <ScrollView contentContainerStyle={styles.container}>
    {Array.from({ length: 20 }, (_, i) => (
      <Text key={i} style={styles.text}>Item {i + 1}</Text>
    ))}
  </ScrollView>
);

const styles = StyleSheet.create({
  container: { padding: 10 },
  text: { fontSize: 16, marginVertical: 5 },
});

export default App;

Here, we dynamically generate 20 items and render them inside a ScrollView.

7 . FlatList

The FlatList component is designed for rendering large datasets efficiently. It only renders items currently visible on the screen, significantly improving performance.

Example: Rendering a List

import React from 'react';
import { FlatList, Text, View, StyleSheet } from 'react-native';

const data = [
  { id: '1', name: 'Item 1' },
  { id: '2', name: 'Item 2' },
  { id: '3', name: 'Item 3' },
];

const App = () => (
  <FlatList
    data={data}
    keyExtractor={(item) => item.id}
    renderItem={({ item }) => (
      <View style={styles.item}>
        <Text style={styles.text}>{item.name}</Text>
      </View>
    )}
  />
);

const styles = StyleSheet.create({
  item: {
    padding: 20,
    borderBottomWidth: 1,
    borderBottomColor: '#ccc',
  },
  text: {
    fontSize: 18,
  },
});

export default App;

Key Difference Between FlatList and ScrollView:

Use FlatList for large, dynamic datasets to optimize performance.
Use ScrollView for smaller datasets or static content.

Styling in React Native

Styling in React Native is achieved using the StyleSheet API. It borrows heavily from CSS but is tailored to work with native platforms for optimal performance.

1 . StyleSheet API

The StyleSheet API provides a way to define styles separately and reuse them across components.

Example: Creating Reusable Styles

import React from 'react';
import { View, Text, StyleSheet } from 'react-native';

const App = () => (
  <View style={styles.container}>
    <Text style={styles.text}>Reusable Styles with StyleSheet</Text>
  </View>
);

const styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
    backgroundColor: '#f0f0f0',
  },
  text: {
    fontSize: 20,
    color: 'blue',
  },
});

export default App;

2 . Flexbox Layout

React Native employs Flexbox for layout management. Flexbox helps to define the alignment, distribution, and spacing of elements within a container.

Example: Aligning Items Horizontally

const styles = StyleSheet.create({
  container: {
    flex: 1,
    flexDirection: 'row',
    justifyContent: 'space-between',
    alignItems: 'center',
    padding: 10,
  },
});

3 . Platform-Specific Styling

React Native allows platform-specific styles using the Platform module.

Example: Conditional Styling

import { Platform, StyleSheet } from 'react-native';

const styles = StyleSheet.create({
  text: {
    fontSize: Platform.OS === 'ios' ? 20 : 18,
    color: Platform.OS === 'ios' ? 'blue' : 'green',
  },
});

Props and State Management

1 . Props

Props allow you to pass data from a parent component to a child component.

Example: Custom Greeting Component

import React from 'react';
import { Text } from 'react-native';

const Greeting = ({ name }: { name: string }) => (
  <Text>Hello, {name}!</Text>
);

const App = () => <Greeting name="React Native" />;

export default App;

2 . State Management with useState

The useState hook is used to manage state in functional components.

Example: Counter Component

import React, { useState } from 'react';
import { View, Text, Button, StyleSheet } from 'react-native';

const Counter = () => {
  const [count, setCount] = useState<number>(0);

  return (
    <View style={styles.container}>
      <Text style={styles.text}>Count: {count}</Text>
      <Button title="Increase" onPress={() => setCount(count + 1)} />
    </View>
  );
};

const styles = StyleSheet.create({
  container: {
    padding: 20,
  },
  text: {
    fontSize: 18,
    marginBottom: 10,
  },
});

export default Counter;

3 . Typing Props with TypeScript

Using TypeScript ensures type safety when passing props.

Example: Typing Props

interface GreetingProps {
  name: string;
}

const Greeting = ({ name }: GreetingProps) => (
  <Text>Hello, {name}!</Text>
);

That's it for today. In the next part of this series, we’ll explore advanced topics like navigation, animations, hooks, and working with APIs.

#ReactNative #TypeScript #MobileDevelopment #SoftwareEngineering #DevCommunity

Leverage ETS for Shared State in Phoenix

Rushikesh Pandit — Mon, 09 Dec 2024 13:45:00 +0000

When building web applications, managing shared state efficiently is often a challenge. For Elixir developers, ETS (Erlang Term Storage) provides an incredibly powerful tool to tackle this problem. ETS is a robust, in-memory data store built into the Erlang VM, offering fast lookups, concurrent access, and persistence during a process’s lifetime.

In this blog, we’ll explore how ETS works, why it’s an excellent choice for shared state in Phoenix applications, and demonstrate practical examples with code snippets.

What is ETS?

ETS (Erlang Term Storage) is a highly efficient in-memory storage system available in Elixir and Erlang. It supports storing key-value pairs, lists, and tuples and is designed to handle high-performance operations with concurrent reads and writes. ETS tables live as long as the process that owns them, making them ideal for managing temporary or shared state.

Why Use ETS in Phoenix?

ETS is a great fit for Phoenix applications in scenarios such as:

Caching: Store frequently accessed data, such as API responses or computed results, for quick retrieval.
Session Management: Maintain temporary user session data across requests.
Rate Limiting: Track user activity to enforce API rate limits.
Real-Time Data Sharing: Share data between processes efficiently.

ETS Basics

To get started, let’s create and manipulate a simple ETS table. You can create a table using :ets.new/2 and interact with it using functions like :ets.insert/2 and :ets.lookup/2.

# Creating an ETS table
table = :ets.new(:example_table, [:set, :public])

# Inserting data
:ets.insert(table, {:key, "value"})

# Retrieving data
case :ets.lookup(table, :key) do
  [{:key, value}] -> IO.puts("Found: #{value}")
  [] -> IO.puts("Not found")
end

Using ETS in Phoenix

Let’s dive into a practical example: caching frequently accessed data in a Phoenix application.

1. ETS for Caching API Data

Suppose you have a Phoenix controller that fetches data from an external API. Instead of fetching the data on every request, you can cache the result in ETS.

ETS Cache Setup

Create a module to manage your ETS table:

defmodule MyApp.Cache do
  @table :api_cache

  def start_link do
    :ets.new(@table, [:named_table, :set, :public, read_concurrency: true])
    {:ok, %{}}
  end

  def put(key, value) do
    :ets.insert(@table, {key, value})
  end

  def get(key) do
    case :ets.lookup(@table, key) do
      [{^key, value}] -> {:ok, value}
      [] -> :error
    end
  end
end

Fetching and Caching API Data

Use this module in your controller:

defmodule MyAppWeb.PageController do
  use MyAppWeb, :controller

  alias MyApp.Cache

  def index(conn, _params) do
    data =
      case Cache.get(:api_data) do
        {:ok, cached_data} ->
          cached_data

        :error ->
          # Fetch data from external API
          api_data = fetch_data_from_api()
          Cache.put(:api_data, api_data)
          api_data
      end

    render(conn, "index.html", data: data)
  end

  defp fetch_data_from_api do
    # Simulated API call
    %{key: "value", timestamp: DateTime.utc_now()}
  end
end

Now, subsequent requests to index/2 will retrieve data from the ETS cache instead of making repeated API calls.

2. Rate Limiting with ETS

Another practical use case is rate limiting. You can use ETS to track how many requests a user has made within a given time window.

Rate Limiter Module

defmodule MyApp.RateLimiter do
  @table :rate_limiter

  def start_link do
    :ets.new(@table, [:named_table, :set, :public])
    {:ok, %{}}
  end

  def allow?(user_id, limit \\ 10) do
    case :ets.lookup(@table, user_id) do
      [{^user_id, count}] when count >= limit ->
        false

      [{^user_id, count}] ->
        :ets.insert(@table, {user_id, count + 1})
        true

      [] ->
        :ets.insert(@table, {user_id, 1})
        true
    end
  end
end

Using the Rate Limiter

Integrate it into a Phoenix controller to enforce limits:

defmodule MyAppWeb.ApiController do
  use MyAppWeb, :controller

  alias MyApp.RateLimiter

  def index(conn, _params) do
    user_id = get_user_id(conn)

    if RateLimiter.allow?(user_id) do
      json(conn, %{message: "Request allowed"})
    else
      conn
      |> put_status(:too_many_requests)
      |> json(%{error: "Rate limit exceeded"})
    end
  end

  defp get_user_id(conn) do
    # Example: extract user ID from session or token
    conn.assigns[:current_user].id
  end
end

This setup ensures that a user cannot exceed the specified request limit, and ETS handles the tracking efficiently.

Advanced ETS Tips

Named Tables: Use named tables ([:named_table]) for global access across processes.
Concurrency Options: Use :read_concurrency and :write_concurrency for performance optimization in read-heavy or write-heavy scenarios.
Persistence: Combine ETS with :dets (Disk ETS) to persist data across application restarts.

Limitations of ETS
While ETS is powerful, it’s important to be aware of its limitations:

Table Lifespan: Tables are tied to the lifecycle of their owning process. If the process crashes, the table is lost.
Manual Garbage Collection: ETS doesn’t automatically manage expired data. You’ll need to implement a cleanup mechanism if necessary.
Cluster Awareness: ETS is not distributed across nodes in a cluster. For distributed setups, consider using Mnesia or a database.

ETS is a fantastic tool for managing shared state in Phoenix applications. Its simplicity and speed make it ideal for caching, rate limiting, and real-time data sharing. However, understanding its limitations is key to using it effectively.

Have you used ETS in your Phoenix projects? Share your experiences in the comments or let me know what other ETS use cases you'd like to explore!

Feel free to reach out if you need help.

LinkedIn: https://www.linkedin.com/in/rushikesh-pandit
GitHub: https://github.com/rushikeshpandit
Portfolio: https://www.rushikeshpandit.in

#myelixirstatus , #elixir , #phoenixframework

Harness PubSub for Real-Time Features in Phoenix Framework

Rushikesh Pandit — Mon, 02 Dec 2024 13:03:14 +0000

When it comes to building real-time web applications, the Phoenix framework is hard to beat. At the heart of its real-time capabilities lies Phoenix.PubSub, a powerful messaging system that allows processes to subscribe to and broadcast messages within an application. Whether you’re building live notifications, collaborative tools, or event-driven systems, PubSub is your go-to tool.

In this blog, we’ll explore how Phoenix.PubSub works, dive into practical use cases, and demonstrate step-by-step examples to integrate it into your projects.

What is Phoenix.PubSub?

Phoenix.PubSub is a publish-subscribe mechanism built into the Phoenix framework. It allows you to broadcast messages to multiple subscribers efficiently, enabling real-time communication across your application.

Key Concepts:

Publishers: Send messages to a specific topic.
Subscribers: Listen for messages on topics they are interested in.
Topics: Strings representing the channel for communication (e.g., "notifications", "room:lobby"). PubSub is transport-agnostic, meaning it can work seamlessly across distributed systems.

Why Use PubSub?

PubSub is an excellent fit for scenarios like:

Real-time notifications: Push updates instantly to users (e.g., alerts, badges).
Collaborative tools: Enable live edits or actions in shared environments (e.g., Google Docs-style collaboration).
Event broadcasting: Notify multiple processes of significant events (e.g., user activity).
Scalability: Distribute messages across nodes in a clustered environment.

Setting Up PubSub

PubSub is automatically included in new Phoenix applications, but to use it effectively, let’s break down the setup.

1. Configuration
Ensure your application’s PubSub module is defined in lib/my_app/application.ex. It’s typically added by default.

defmodule MyApp.Application do
  use Application

  def start(_type, _args) do
    children = [
      {Phoenix.PubSub, name: MyApp.PubSub}
    ]

    opts = [strategy: :one_for_one, name: MyApp.Supervisor]
    Supervisor.start_link(children, opts)
  end
end

2. Broadcasting Messages

Use Phoenix.PubSub.broadcast/3 to send messages to a specific topic.

Phoenix.PubSub.broadcast(MyApp.PubSub, "notifications", %{message: "New user signed up!"})

3. Subscribing to Topics

Processes can subscribe to a topic using Phoenix.PubSub.subscribe/2.

Phoenix.PubSub.subscribe(MyApp.PubSub, "notifications")

Real-World Example: Notifications System

Let’s build a simple notification system where users receive real-time updates whenever a new notification is added.

Creating the PubSub Integration

1. Subscribe to Notifications
When a LiveView mounts, subscribe the process to the "notifications" topic.

def mount(_params, _session, socket) do
  Phoenix.PubSub.subscribe(MyApp.PubSub, "notifications")
  {:ok, assign(socket, notifications: [])}
end

2. Handle Incoming Messages
When a message is broadcasted, handle it with handle_info/2 and update the LiveView state.

def handle_info(%{message: message}, socket) do
  {:noreply, assign(socket, notifications: [message | socket.assigns.notifications])}
end

3. Broadcast Notifications
Trigger broadcasts from any part of the app (e.g., a controller or background worker).

def notify_users(message) do
  Phoenix.PubSub.broadcast(MyApp.PubSub, "notifications", %{message: message})
end

LiveView Template

<div id="notifications">
  <h3>Notifications</h3>
  <ul>
    <%= for notification <- @notifications do %>
      <li><%= notification %></li>
    <% end %>
  </ul>
</div>

With these steps, users will receive live updates in their notifications list whenever notify_users/1 is called.

Advanced Use Case: Collaborative Editing

PubSub shines in collaborative tools. For instance, imagine a real-time collaborative text editor where multiple users edit the same document.

Broadcasting Edits

def handle_event("edit", %{"content" => content}, socket) do
  Phoenix.PubSub.broadcast(MyApp.PubSub, "document:123", %{content: content})
  {:noreply, socket}
end

Subscribing to Edits

def mount(_params, _session, socket) do
  Phoenix.PubSub.subscribe(MyApp.PubSub, "document:123")
  {:ok, assign(socket, content: "")}
end

def handle_info(%{content: content}, socket) do
  {:noreply, assign(socket, content: content)}
end

Testing PubSub

You can test your PubSub implementation easily using iex. Open multiple iex sessions and ensure they subscribe to the same topic:

Phoenix.PubSub.subscribe(MyApp.PubSub, "test_topic")

Phoenix.PubSub.broadcast(MyApp.PubSub, "test_topic", %{data: "Hello, PubSub!"})

All subscribers to "test_topic" should receive the broadcast message.

Scaling PubSub Across Nodes

Phoenix.PubSub supports distributed systems out of the box. To enable clustering:

Add :libcluster to your dependencies.
Configure clustering in config/runtime.exs:

config :libcluster,
  topologies: [
    example: [
      strategy: Cluster.Strategy.Gossip
    ]
  ]

Start your application on multiple nodes, and messages will seamlessly propagate across them.

Phoenix.PubSub is a powerful tool for building real-time features in Elixir applications. Whether you’re creating a simple notification system or scaling to a distributed collaborative environment, PubSub provides the flexibility and performance you need.

If you’ve built something cool with Phoenix.PubSub, let me know in the comments—I’d love to hear about your experience!

Feel free to reach out if you need help.

LinkedIn: https://www.linkedin.com/in/rushikesh-pandit
GitHub: https://github.com/rushikeshpandit
Portfolio: https://www.rushikeshpandit.in

#myelixirstatus , #elixir , #phoenixframework

Optimize LiveView Performance with Temporary Assigns

Rushikesh Pandit — Tue, 26 Nov 2024 13:23:59 +0000

When working with Phoenix LiveView, you often juggle a lot of data while building interactive, real-time web applications. One challenge developers face is managing memory efficiently, especially for components or pages that render frequently changing data. Temporary assigns in LiveView provide a smart way to handle this challenge.

In this blog, we’ll dive deep into what temporary assigns are, why you should use them, and provide practical examples to help you harness their power effectively.

What Are Temporary Assigns?

Temporary assigns are a feature of Phoenix LiveView that lets you specify certain assigns to be reset to their default value after every render. This means LiveView doesn’t persist these values in memory, which can save significant resources when dealing with large or frequently changing data.

Without temporary assigns, all the assigns in your LiveView process are kept in memory between renders. While this is fine for small, static data, it can quickly add up when you’re working with dynamic content, such as lists, logs, or real-time updates.

Why Use Temporary Assigns?

Here are a few scenarios where temporary assigns can be particularly helpful:

Reducing Memory Usage: If you have a LiveView that frequently updates large datasets (e.g., a chat app or a live dashboard), temporary assigns prevent stale data from piling up in memory.
Improving Performance: By resetting unused data after each render, you reduce the load on your LiveView processes, keeping them lightweight and efficient.
Preventing Memory Leaks: Long-running LiveView processes with large, unused assigns can inadvertently cause memory leaks. Temporary assigns are a built-in safeguard against this.

Setting Up Temporary Assigns

To enable temporary assigns, use the temporary_assigns key in the socket's assign function. Here’s a basic example:

def mount(_params, _session, socket) do
  {:ok, 
   assign(socket, 
     messages: [], 
     temporary_assigns: [messages: []]
   )}
end

In this example, we’ve marked the messages assign as temporary. After every render, messages will reset to an empty list ([]), regardless of its previous state.

A Practical Example: Live Chat with Temporary Assigns

Let’s build a live chat application where messages are sent in real time. Without temporary assigns, the LiveView process would hold onto every single message, leading to bloated memory usage over time. Instead, we’ll use temporary assigns to keep the memory footprint minimal.

LiveView Module

defmodule MyAppWeb.ChatLive do
  use Phoenix.LiveView

  def mount(_params, _session, socket) do
    {:ok, 
     assign(socket, 
       messages: [], 
       temporary_assigns: [messages: []]
     )}
  end

  def handle_event("send_message", %{"content" => content}, socket) do
    message = %{content: content, timestamp: DateTime.utc_now()}

    # Append the new message to the messages list
    {:noreply, assign(socket, messages: [message])}
  end
end

LiveView Template

<div id="chat-container">
  <div id="messages">
    <%= for message <- @messages do %>
      <div class="message">
        <p><%= message.content %></p>
        <small><%= message.timestamp %></small>
      </div>
    <% end %>
  </div>

  <form phx-submit="send_message">
    <input type="text" name="content" placeholder="Type a message..." required />
    <button type="submit">Send</button>
  </form>
</div>

In this example:

@messages is marked as a temporary assign, so it resets to [] after each render.
The messages list is only populated during the render lifecycle, reducing the memory overhead.

Testing Temporary Assigns in Action

To see the difference temporary assigns make, you can log the state of the socket after each event:

def handle_event("send_message", %{"content" => content}, socket) do
  message = %{content: content, timestamp: DateTime.utc_now()}
  updated_socket = assign(socket, messages: [message])

  IO.inspect(updated_socket.assigns, label: "Socket Assigns After Render")

  {:noreply, updated_socket}
end

Run the application and observe how @messages is reset to its default state ([]) after each render.

When Not to Use Temporary Assigns

While temporary assigns are incredibly powerful, they aren’t always the right tool. Avoid using them if:

You need persistent data: For example, user session data or application state that shouldn’t be lost between renders.
The cost of re-fetching data is too high: If the data comes from an external API or a complex computation, temporary assigns might introduce unnecessary overhead.

Advanced Use Cases

Combining Temporary Assigns with Streams

For large datasets that change incrementally (e.g., logs or paginated results), combine temporary assigns with LiveView streams for optimal performance.

def mount(_params, _session, socket) do
  {:ok, 
   socket
   |> assign(:logs, [])
   |> stream(:logs, [])
   |> assign(temporary_assigns: [logs: []])
  }
end

This approach ensures that only the current batch of logs is in memory, while older logs are efficiently managed using streams.

Final Thoughts

Temporary assigns in Phoenix LiveView are an elegant solution to a common problem in real-time web development: managing memory while maintaining interactivity. By understanding when and how to use them, you can build scalable, performant applications without sacrificing user experience.

If you’ve used temporary assigns in your projects or have tips to share, let me know in the comments—I’d love to hear how you’re optimizing your LiveView apps!

Feel free to reach out if you need help.

LinkedIn: https://www.linkedin.com/in/rushikesh-pandit
GitHub: https://github.com/rushikeshpandit
Portfolio: https://www.rushikeshpandit.in

#myelixirstatus , #elixir , #phoenixframework

Understanding Hooks in the Phoenix Framework

Rushikesh Pandit — Mon, 30 Sep 2024 14:25:12 +0000

Hello everyone,

I hope this message finds you in good spirits. In the current piece, we will focus our attention on the concept of hooks in the Phoneix app.

Phoenix Framework Hooks are a great extension of LiveView improvements by executing custom JavaScript on the client side. It enables you to use JavaScript directly, which isn’t feasible or efficient only with live view, where there is a need for dynamic behaviour.

In the Phoenix Framework context, hooks are simply a method that allows triggering JavaScript when a given element of the LiveView is rendered or updated in the DOM.

Hooks help in smoothly adding any form of interaction with the LiveView that is already painted on the browser. Most of the interaction with Phoenix LiveView is that the contents are rendered on the server side. However, there are cases such as when the UI is animated, or some other javascript library is turning up that some actions on the front end have to take place in real-time to perform certain actions on the user interface.

Importantly, while Phoenix LiveView efficiently handles state and UI updates from the server, there are cases when client-side code is required. For example:

Third-Party Libraries: Imagine you're integrating a charting library like Chart.js or a UI toolkit that requires client-side code to initialise after a LiveView page is loaded.
Custom DOM Manipulation: Sometimes, you need to apply JavaScript directly to an element after it's rendered.
Animations: There are cases where animations triggered by JavaScript can enhance the user experience, such as sliding in a notification bar or creating modal popups.
Handling Real-Time Events: For real-time event handling beyond what Phoenix Channels or LiveView directly provide, you may need JavaScript to react to specific events in the front end.

With the introduction of Hooks, it has become possible to enhance client-side functionalities without losing the merits of server-side rendered pages.

Adding Support For Hooks To Phoenix

Hooks primarily are instantiated in the LiveSocket object in JavaScript. In your LiveView templates, you include hooks to certain elements and every time that element gets rendered or is updated, that hook will run its Javascript code.

Step 1: Define the Hook in JavaScript

To get started, create a hook in a javascript file that is prepared to cover LiveView features.

Usually, the importation of the LiveSocket and the initialisation of the custom hooks are found in the ‘assets/js/app.js’ file in Phoenix.
Here’s how you can define a simple hook:

let Hooks = {};

Hooks.ExampleHook = {
  mounted() {
    console.log("Hook mounted!");
    // Your logic when the hook is attached to an element
  },
  updated() {
    console.log("Hook updated!");
    // Logic when the DOM updates with this element
  },
  destroyed() {
    console.log("Hook destroyed!");
    // Cleanup logic when the element is removed
  }
};

let liveSocket = new LiveSocket("/live", Socket, {
  hooks: Hooks
});

liveSocket.connect();

This example defines a hook named ExampleHook that can respond to lifecycle events such as mounted(), updated(), and destroyed().

mounted(): Executes when the element is first rendered.
updated(): Executes when the element updates (such as when LiveView re-renders).
destroyed(): Executes when the element is removed from the DOM.

Step 2: Use the Hook in Your LiveView Template

After defining your hook in JavaScript, you need to attach it to an element in your LiveView template. You can do this using the phx-hook attribute.

<div id="example" phx-hook="ExampleHook">
  <!-- Your dynamic content goes here -->
</div>

The phx-hook attribute connects the HTML element to the ExampleHook you defined in JavaScript. When this element is rendered or updated by LiveView, the appropriate JavaScript lifecycle methods (e.g., mounted, updated, etc.) will be triggered.

Step 3: Add Custom Behavior

Let’s add some custom behaviour to the hook to demonstrate its capabilities. For example, let's say you want to focus an input field as soon as it is mounted:

Hooks.FocusInput = {
  mounted() {
    this.el.focus();
  },
  updated() {
    this.el.focus();
  }
};

This FocusInput hook will focus the input field whenever it is mounted or updated.

Now, attach this hook to your LiveView template:

<input type="text" phx-hook="FocusInput" placeholder="Focus me!">

When this input field is rendered, it will automatically receive focus, creating a smooth user experience.

Implementing a Chart.js Hook

For a more advanced example, use hooks to integrate a charting library such as Chart.js into a LiveView page.

Step 1: Define the Hook in app.js.

Hooks.Chart = {
  mounted() {
    let ctx = this.el.getContext('2d');
    this.chart = new Chart(ctx, {
      type: 'bar',
      data: {
        labels: ['Red', 'Blue', 'Yellow', 'Green', 'Purple', 'Orange'],
        datasets: [{
          label: '# of Votes',
          data: [12, 19, 3, 5, 2, 3],
          backgroundColor: 'rgba(255, 99, 132, 0.2)',
          borderColor: 'rgba(255, 99, 132, 1)',
          borderWidth: 1
        }]
      },
      options: {
        scales: {
          y: {
            beginAtZero: true
          }
        }
      }
    });
  },
  updated() {
    this.chart.update();
  },
  destroyed() {
    this.chart.destroy();
  }
};

Step 2: Attach the Hook in Your Template

<canvas id="myChart" phx-hook="Chart" width="400" height="400"></canvas>

Now, whenever this canvas element is rendered by LiveView, the chart will be drawn using Chart.js.

That's it for the day. In the next part, we will go through some more concepts of the Phoenix framework.

Feel free to reach out if you need help.

LinkedIn: https://www.linkedin.com/in/rushikesh-pandit
GitHub: https://github.com/rushikeshpandit
Portfolio: https://www.rushikeshpandit.in

#myelixirstatus , #elixir , #phoenixframework

Mastering Phoenix Framework - Part 3

Rushikesh Pandit — Mon, 19 Aug 2024 14:17:55 +0000

Hi folks,

I hope you are doing well. In this blog, we will look at some essential concepts of the Phoenix app.

Live View

To create a live view we need to enter the following command.

mix phx.gen.live Accounts User users name:string age:integer

The first argument is the context module, which serves as an API boundary for related resources. If the context already exists, it will be augmented with functions for the new resource.

The second argument is the schema module, which maps database fields to an Elixir struct.

The remaining arguments are the schema module's plural name (used as the table name) and an optional list of attributes with their names and types.

Check out the sample code for live view.

lib/my_app_web/live/my_live_view.ex

defmodule MyAppWeb.MyLiveView do
  use MyAppWeb, :live_view

  def render(assigns) do
    ~H"""
    <div>
      Hi from Live View.
    </div>
    """
  end

Now our live view is ready, so we need to add it to our router to use it. To do this, add the following code to your router.ex

scope "/", MyAppWeb do
    pipe_through :browser

    live "/", MyLiveView
end

Now, visit http://localhost:4000/ to see the live view in action.

Live Component

To create a live component we need to create a new file named my_component.ex in the following directory.

lib/my_app_web/live/my_component.ex

Add the following content in the above file.

defmodule MyAppWeb.MyComponent do
  use MyAppWeb, :live_component

  def render(assigns) do
    ~H"""
    <div>
      <h1><%= @title %></h1>
      <p><%= @description %></p>
    </div>
    """
  end
end

So, this component expects 2 values such as title and description. We need to pass these 2 values whenever we want to consume this component in our live view. To do this, we need to update our live view as follows.

lib/my_app_web/live/my_live_view.ex

defmodule MyAppWeb.MyLiveView do
  use MyAppWeb, :live_view
  alias MyAppWeb.MyComponent

  def render(assigns) do
    ~H"""
    <div>
      <.live_component module={MyComponent}
        id= "my-component"
        title={@title}
        description={@description}
      />
    </div>
    """
  end

  def mount(_params, _session, socket) do
    {:ok, assign(socket, title: "Hello, World!", description: "This is a description.")}
  end
end

In this example:

The live_component function is used to render MyAppWeb.MyComponent.
The module attribute is used to specify the component module.
The id is required and must be unique for each instance of the component.
title and description are passed as assigns to the component using {} syntax.

Access the Data in the Component:

Inside our live component's render function, we can access the passed data using @title and @description assigns.

Navigation

There are 2 types of navigation we are using in the Phoenix Framework.

Server-side navigation
Client-side navigation

Let's take a look at them one by one.

1. Server-side navigation

- `redirect/2`

Sends redirect response to the given URL. For security, :to only accept paths. Use the :external option to redirect to any URL. The response will be sent with the status code defined within the connection, via Plug.Conn.put_status/2. If no status code is set, a 302 response is sent.

Example

redirect(conn, to: "/login")

redirect(conn, external: "https://elixir-lang.org")

- `push_navigate/2`

The current LiveView will be shut down and a new one will be mounted in its place, without reloading the whole page. This can also be used to remount the same LiveView, in case you want to start fresh.

Option

:to - the required path to link to. It must always be a local path
:replace - the flag to replace the current history or push a new state. Defaults false.

Example

{:noreply, push_navigate(socket, to: "/")}
{:noreply, push_navigate(socket, to: "/", replace: true)}

- `push_patch/2`

When navigating to the current LiveView, handle_params/3 is immediately invoked to handle the change of params and URL state. Then the new state is pushed to the client, without reloading the whole page while also maintaining the current scroll position.

Option

:to - the required path to link to. It must always be a local path
:replace - the flag to replace the current history or push a new state. Defaults false.

Example

{:noreply, push_patch(socket, to: "/")}
{:noreply, push_patch(socket, to: "/", replace: true)}

2. Client-side navigation

- `link/1`

Generates a link to a given route. To navigate across pages, using traditional browser navigation, use the href attribute. To patch the current LiveView or navigate across LiveViews, use the patch and navigate respectively.

Attributes
navigate (:string) - Navigates from a LiveView to a new LiveView. The browser page is kept, but a new LiveView process is mounted and its content on the page is reloaded. It is only possible to navigate between LiveViews declared under the same router Phoenix.LiveView.Router.live_session/3. Otherwise, a full browser redirect is used.

patch (:string) - Patches the current LiveView. The handle_params callback of the current LiveView will be invoked and the minimum content will be sent over the wire, as any other LiveView diff.

href (:any) - Uses traditional browser navigation to the new location. This means the whole page is reloaded on the browser.

replace (:boolean) - When using :patch or :navigate, should the browser's history be replaced with pushState?

Defaults to false.

method (:string) - The HTTP method to use with the link. This is intended for usage outside of LiveView and therefore only works with the href={...} attribute. It has no effect on the patch and navigate instructions. In case the method does not work, the link is generated inside the form which sets the proper information. To submit the form, JavaScript must be enabled in the browser. Defaults to get.

csrf_token (:any) - A boolean or custom token to use for links with an HTTP method other than get. Defaults to true. Global attributes are accepted. Additional HTML attributes are added to the tag. Supports all globals plus: ["download", "hreflang", "referrerpolicy", "rel", "target", "type"].

`Slots`

inner_block (required) - The content rendered inside of the a tag.

Example

<.link href="/">Regular anchor link</.link>

<.link navigate={~p"/"} class="underline">home</.link>

<.link navigate={~p"/?sort=asc"} replace={false}>
  Sort By Price
</.link>

<.link patch={~p"/details"}>view details</.link>

<.link href={URI.parse("https://elixir-lang.org")}>hello</.link>

<.link href="/the_world" method="delete" data-confirm="Really?">delete</.link>

That's it for the day. In the next part, we will go through some more concepts of the Phoenix framework.

Feel free to reach out if you need help.

LinkedIn: https://www.linkedin.com/in/rushikesh-pandit-646834100/
GitHub: https://github.com/rushikeshpandit
Portfolio: https://www.rushikeshpandit.in

#myelixirstatus , #liveviewnative , #dockyard , #elixir , #phoenixframework

Mastering Phoenix Framework - Part 2

Rushikesh Pandit — Mon, 12 Aug 2024 13:40:56 +0000

Hi All,

This blog is dedicated to the directory structure for the Phoenix Framework application.

Checkout my previous blogs here, if you want to know more about Phoenix Framework Application.

Mastering Phoenix Framework - Introduction

Mastering Phoenix Framework - Part 1

Now, I think we should start with today's topic. Your Phoenix Framework application's directory structure looks similar to the one shown below.

Directory structure

/my_phoenix_app
├── /assets
│   ├── /js
│   ├── /css
│   └── /static
├── /config
│   ├── config.exs
│   ├── dev.exs
│   ├── prod.exs
│   └── test.exs
├── /deps
├── /lib
│   ├── /my_phoenix_app
│   └── /my_phoenix_app_web
│       ├── /controllers
│       ├── /templates
│       ├── /channels
│       ├── /views
│       ├── /live
│       ├── router.ex
│       └── endpoint.ex
├── /priv
│   ├── /static
│   └── /repo
├── /test
│   ├── /my_phoenix_app_web
│   └── /support
└── mix.exs

Let's take a detailed look at the directory structure.

/assets: Contains front-end assets like JavaScript, CSS, images, and other static files.
- /js: JavaScript files.
- /css: CSS files.
- /static: Static files such as images.
/config: Configuration files for the application.
- config.exs: Main configuration file.
- dev.exs: Configuration specific to the development environment.
- prod.exs: Configuration specific to the production environment.
- test.exs: Configuration specific to the test environment.
/deps: Dependencies managed by Mix, Elixir's build tool.
/lib: The main directory for your application's code.

/lib/my_phoenix_app: Your application code, including contexts and business logic.
/lib/my_phoenix_app_web: The web interface of your application.
- /controllers: Controllers handling HTTP requests and responses.
- /templates: Templates for rendering HTML views.
- /channels: WebSocket channels for real-time features.
- /views: View modules that render templates.
- /live: LiveView modules for real-time updates without JavaScript.
- /router.ex: Defines routes for the application.
- /endpoint.ex: Endpoint configuration for handling requests.

/priv: Contains private files used by the application.
- /priv/static: Compiled static assets.
- /priv/repo: Database-related files, including migrations and seeds.
/test: Test files for the application.
- /test/my_phoenix_app_web: Tests for the web interface.
- /test/support: Helper modules and configuration for tests.
mix.exs: The main build configuration file for the project.

That's it for the day. I hope you have enjoyed this blog. In the next part, we will go through some more concepts of the Phoenix framework.

If you have any suggestions/doubts, feel free to reach out via one of the following methods.

LinkedIn: https://www.linkedin.com/in/rushikesh-pandit/
GitHub: https://github.com/rushikeshpandit
Portfolio: https://www.rushikeshpandit.in

#myelixirstatus , #liveviewnative , #dockyard , #elixir , #phoenixframework