DEV Community: Marty Roque

How I Removed Redux Toolkit From My React Native App

Marty Roque — Thu, 23 Oct 2025 00:29:58 +0000

I was building a budget tracking app for couples when I noticed something: the code to manage state was overwhelming.

Let me show you what I mean.

The Redux Toolkit Tax

Here's what my budget period management looked like with Redux Toolkit:

periodSlice.ts:

import { createSlice, createAsyncThunk } from '@reduxjs/toolkit';

export const fetchPeriodSettings = createAsyncThunk(
  'period/fetchSettings',
  async (_, { rejectWithValue }) => {
    try {
      const response = await periodService.fetchPeriodSettings();
      return response;
    } catch (error) {
      return rejectWithValue(error.message);
    }
  }
);

export const fetchTransactions = createAsyncThunk(
  'period/fetchTransactions',
  async (_, { rejectWithValue }) => {
    try {
      const transactions = await transactionService.fetchTransactions();
      return transactions;
    } catch (error) {
      return rejectWithValue(error.message);
    }
  }
);

const periodSlice = createSlice({
  name: 'period',
  initialState: {
    settings: null,
    transactions: [],
    periodGroups: { groups: [] },
    activeGroupIndex: -1,
    isLoading: false,
    error: null,
  },
  reducers: {
    setActiveGroupIndex: (state, action) => {
      state.activeGroupIndex = action.payload;
    },
    nextGroup: (state) => {
      if (state.activeGroupIndex < state.periodGroups.groups.length - 1) {
        state.activeGroupIndex += 1;
      }
    },
    previousGroup: (state) => {
      if (state.activeGroupIndex > 0) {
        state.activeGroupIndex -= 1;
      }
    },
  },
  extraReducers: (builder) => {
    builder
      .addCase(fetchPeriodSettings.pending, (state) => {
        state.isLoading = true;
      })
      .addCase(fetchPeriodSettings.fulfilled, (state, action) => {
        state.settings = action.payload;
        state.isLoading = false;
      })
      .addCase(fetchPeriodSettings.rejected, (state, action) => {
        state.error = action.payload;
        state.isLoading = false;
      })
      // ... more cases for fetchTransactions
  },
});

export const { setActiveGroupIndex, nextGroup, previousGroup } = periodSlice.actions;
export default periodSlice.reducer;

store.ts:

import { configureStore } from '@reduxjs/toolkit';
import periodReducer from './slices/periodSlice';
import transactionReducer from './slices/transactionSlice';
import sessionReducer from './slices/sessionSlice';

export const store = configureStore({
  reducer: {
    period: periodReducer,
    transaction: transactionReducer,
    session: sessionReducer,
  },
});

export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

hooks.ts:

import { useDispatch, useSelector } from 'react-redux';
import type { RootState, AppDispatch } from './store';

export const useAppDispatch = useDispatch.withTypes<AppDispatch>();
export const useAppSelector = useSelector.withTypes<RootState>();

That's three files and 150+ lines just for one slice of state. And I still needed to:

Set up selectors
Handle async loading states manually
Connect services to actions
Export and import types everywhere

Redux Toolkit is better than vanilla Redux. But it still felt like I was writing infrastructure instead of features.

What I Actually Needed

Here's the same period management logic:

PeriodStore.ts (everything in one place):

import { Store } from 'nucleux';

class PeriodStore extends Store {
  // State atoms
  public periodSettings = this.atom<PeriodSetting | null>(null);
  public periodGroups = this.atom<GroupingResult>({ groups: [] });
  public activeGroupIndex = this.atom(-1);
  public isLoading = this.atom(false);

  // Derived state
  public activeGroup = this.deriveAtom(
    [this.periodGroups, this.activeGroupIndex],
    (periodGroups, index) => periodGroups.groups[index] ?? null
  );

  // Dependencies
  private periodService = this.inject(PeriodService);
  private transactionStore = this.inject(TransactionStore);

  constructor() {
    super();
    this.loadPeriodSettings(true);
  }

  private async loadPeriodSettings() {
    this.isLoading.value = true;

    const settings = await this.periodService.fetchPeriodSettings();
    this.periodSettings.value = settings;

    if (settings) {
      await this.transactionStore.fetchTransactions();
    }

    this.isLoading.value = false;
  }

  private onTransactionsChange(transactions: Transaction[]) {
    // Logic to handle transactions change
  }

  public nextGroup() {
    const maxIndex = this.periodGroups.value.groups.length - 1;
    if (this.activeGroupIndex.value < maxIndex) {
      this.activeGroupIndex.value += 1;
    }
  }

  public previousGroup() {
    if (this.activeGroupIndex.value > 0) {
      this.activeGroupIndex.value -= 1;
    }
  }
}

export default PeriodStore;

One file. One class. All the logic in one place. No actions, no reducers, no thunks, no extraReducers, no builder pattern.

Using It In Components

Before (Redux Toolkit):

import { useAppDispatch, useAppSelector } from '@/store/hooks';
import { fetchPeriodSettings, nextGroup, previousGroup } from '@/store/slices/periodSlice';

function BudgetScreen() {
  const dispatch = useAppDispatch();
  const activeGroup = useAppSelector((state) => state.period.periodGroups.groups[state.period.activeGroupIndex]);
  const isLoading = useAppSelector((state) => state.period.isLoading);

  useEffect(() => {
    dispatch(fetchPeriodSettings());
  }, [dispatch]);

  const handleNext = () => dispatch(nextGroup());
  const handlePrevious = () => dispatch(previousGroup());

  return (
    <View>
      {isLoading ? <Loader /> : <PeriodView group={activeGroup} />}
      <Button onPress={handlePrevious} title="Previous" />
      <Button onPress={handleNext} title="Next" />
    </View>
  );
}

After:

import { useStore, useValue } from 'nucleux';
import PeriodStore from '@/stores/PeriodStore';

function BudgetScreen() {
  const periodStore = useStore(PeriodStore);
  const activeGroup = useValue(periodStore.activeGroup);
  const isLoading = useValue(periodStore.isLoading);

  return (
    <View>
      {isLoading ? <Loader /> : <PeriodView group={activeGroup} />}
      <Button onPress={periodStore.previousGroup} title="Previous" />
      <Button onPress={periodStore.nextGroup} title="Next" />
    </View>
  );
}

No dispatch. No action creators. No selectors with arrow functions. Just call methods directly on the store.

The Re-Render Win

Here's where it got interesting. With Redux Toolkit, when periodSettings changed, every component using useAppSelector would re-evaluate its selector function. Even components that didn't care about period settings.

My settings screen subscribed to just the session:

function SettingsScreen() {
  const session = useValue(sessionStore.session);
  // Only re-renders when session changes, not when period settings change
}

My budget screen subscribed to period data:

function BudgetScreen() {
  const activeGroup = useValue(periodStore.activeGroup);
  // Only re-renders when activeGroup changes, not when session changes
}

Each component only re-renders when its specific atom changes. Not when the store changes. Not when the slice changes. Just the atom it cares about.

Dependency Injection Without Context

With Redux Toolkit, I had services living outside the store. To use them in thunks, I either imported them directly (tight coupling) or passed them as arguments (tedious).

Now stores can inject other stores and services:

class TransactionStore extends Store {
  // Inject the service this store needs
  private transactionService = this.inject(TransactionService);

  public transactions = this.atom<Transaction[]>([]);

  async fetchTransactions() {
    const data = await this.transactionService.fetchTransactions();
    // ...
    this.transactions.value = data;
  }
}

class PeriodStore extends Store {
  // Inject another store
  private transactionStore = this.inject(TransactionStore);

  constructor() {
    super();

    // React to changes in another store
    this.watchAtom(
      this.transactionStore.transactions,
      (transactions) => {
        // Recalculate periods when transactions change
        this.groupPeriods(transactions);
      }
    );
  }
}

The IoC container handles instantiation. Stores and services are singletons. Dependencies just work.

The Expo Router Reality

Here's what my app/_layout.tsx actually looks like:

import { Stack } from "expo-router";
import SessionProvider from "@/providers/SessionProvider";

export default function RootLayout() {
  return (
    <SessionProvider>
      <Stack screenOptions={{ headerShown: false }}>
        <Stack.Screen name="(tabs)" />
        <Stack.Screen name="(auth)" />
        <Stack.Screen name="(screens)" />
      </Stack>
    </SessionProvider>
  );
}

I still have one provider: SessionProvider. Not for state management—for Expo Router's splash screen and navigation control:

export default function SessionProvider({ children }: SessionProviderProps) {
  const { initialized, session } = useNucleux(SessionStore);

  useEffect(() => {
    if (!initialized) return;

    // Route based on session state
    if (session) {
      router.replace("/(tabs)");
    } else {
      router.replace("/(auth)");
    }
  }, [session, initialized]);

  const onLayoutRootView = useCallback(async () => {
    if (initialized) {
      await SplashScreen.hideAsync();
    }
  }, [initialized]);

  if (!initialized) {
    return null;
  }

  return (
    <SessionContext.Provider value={{ session, onLayoutRootView }}>
      {children}
    </SessionContext.Provider>
  );
}

This provider doesn't manage state. It reads state from SessionStore and controls navigation. The state lives in Nucleux, not Context.

Modern Expo apps often end up with providers for:

Session management (auth routing)
Theme/appearance
Localization
Safe area context (from React Native)
Navigation container

That's 5+ providers in _layout.tsx before you add any state management. With atomic state in stores, you don't add more providers for state.

What About Persistence?

Redux Toolkit needs redux-persist. That's another library, more config, wrapper components, and migration logic.

With atomic state:

class UserPreferencesStore extends Store {
  theme = this.atom('light', { 
    persistence: { persistKey: 'theme' } 
  });

  currency = this.atom('USD', { 
    persistence: { 
      persistKey: 'currency',
      storage: AsyncStorage  // React Native's AsyncStorage
    } 
  });
}

It automatically persists and rehydrates. One line per atom.

The Migration Path

I didn't rewrite everything at once. Here's how I did it:

Week 1: Created SessionStore for auth. Left Redux for everything else.

Week 2: Created TransactionStore. Transactions now lived in atomic state, periods still in Redux.

Week 3: Created PeriodStore. Now PeriodStore could inject TransactionStore and watch for changes.

Week 4: Deleted Redux entirely.

Each store was self-contained. The migration was:

Create the store class
Move logic from slice into store methods
Replace useAppSelector with useValue
Replace dispatch(action()) with store.method()
Delete the slice file

The hardest part was deleting 500 lines of working Redux code.

What I Learned

Redux Toolkit made Redux better. But it still carries the original Redux architecture:

Actions as the API (you call action creators, not methods)
Reducers for updates (even with Immer, you're writing reducers)
Separate selector layer (useAppSelector everywhere)
External async handling (thunks)
Manual typing (type RootState, type AppDispatch)

The atomic pattern flips this:

Stores as the API (you call methods directly)
Atoms for updates (just set .value)
No selector layer (subscribe to atoms directly)
Internal async handling (methods are just async)
Inferred typing (TypeScript figures it out)

The Results

Before:

5 providers in _layout.tsx (Session, Redux, Theme, Safe Area, Stack)
~1200 lines across slice files, store config, and hooks
Manual selector optimization with reselect
8-12 files per feature (slice, selectors, thunks, types, hooks)

After:

1 provider in _layout.tsx (just SessionProvider for routing)
~600 lines of store code (just the stores)
Automatic atomic updates
3-4 files per feature (store, service, types, components)

Developer Experience: New features went from taking 2-3 days to taking hours. No more "which file does this go in?" Everything for a feature lives in its store.

Why This Worked For Me

I'm not saying Redux Toolkit is wrong for everyone. But if you're:

Building an Expo/React Native app
Managing complex, interconnected state
Writing more Redux boilerplate than business logic
Wanting built-in persistence
Looking for better TypeScript inference

You might want to try atomic state management.

I built this pattern into a library called Nucleux because I kept using it across projects. But the concepts work without the library:

Atoms over global state trees
Classes over actions/reducers
Dependency injection over imports
Direct method calls over dispatch

The biggest win wasn't code reduction—it was clarity. My budget feature's logic lives in PeriodStore. My transaction logic lives in TransactionStore. When stores need to communicate, they inject each other. No indirection, no dispatch, no selectors.

Try It Yourself

Want to see if this works for your app? Start small:

Pick one Redux slice (sessions work well)
Convert it to a store class
Compare the code

If you like it, keep going. If not, they can coexist during evaluation.

The repo with examples: github.com/martyroque/nucleux

Demo sandbox: codesandbox.io/p/sandbox/nucleux-react-qw58s4

Would love to hear your thoughts—especially if you've hit similar challenges with Redux Toolkit.

Building Duetto - a privacy-first budget app for couples. The entire app uses atomic state management, and it's changed how fast I can ship features.

Building Scalable React Native Apps with Nucleux and Supabase

Marty Roque — Tue, 15 Jul 2025 03:00:40 +0000

Combining Supabase's powerful backend services with Nucleux's atomic state management creates a clean, scalable architecture for React Native applications. This guide shows you how to structure authentication and API services using class-based stores that naturally organize your application logic.

The Architecture Pattern

We'll build a three-layer architecture that separates concerns cleanly:

ApiService: Handles Supabase client configuration and lifecycle
SessionStore: Manages authentication state and user sessions
Auth Component: Provides the user interface for authentication

This pattern leverages Nucleux's dependency injection to create a clean separation where each layer has a single responsibility.

Setting Up the API Service

First, create a centralized API service that manages the Supabase client:

// src/services/ApiService.ts
import AsyncStorage from "@react-native-async-storage/async-storage";
import { createClient, SupabaseClient } from "@supabase/supabase-js";
import { Store } from "nucleux";
import { AppState, NativeEventSubscription, Platform } from "react-native";
import "react-native-url-polyfill/auto";

if (
  process.env.EXPO_PUBLIC_SUPABASE_URL === undefined ||
  process.env.EXPO_PUBLIC_SUPABASE_ANON_KEY === undefined
) {
  throw new Error("Missing critical environment variables");
}

class ApiService extends Store {
  public apiClient: SupabaseClient;
  private appStateSubscription: NativeEventSubscription;

  constructor() {
    super();

    this.apiClient = createClient(
      process.env.EXPO_PUBLIC_SUPABASE_URL || "",
      process.env.EXPO_PUBLIC_SUPABASE_ANON_KEY || "",
      {
        auth: {
          storage: AsyncStorage,
          autoRefreshToken: true,
          persistSession: true,
          detectSessionInUrl: false,
        },
      }
    );

    this.appStateSubscription = AppState.addEventListener("change", (state) => {
      if (state === "active") {
        this.apiClient.auth.startAutoRefresh();
      } else {
        this.apiClient.auth.stopAutoRefresh();
      }
    });
  }

  destroy() {
    this.appStateSubscription.remove();
    super.destroy();
  }
}

export default ApiService;

Key Benefits:

Centralized Configuration: Single place to manage Supabase setup
Lifecycle Management: Properly manages token refresh based on app state

Creating the Session Store

The SessionStore handles all authentication logic while staying completely decoupled from UI concerns:

// src/stores/SessionStore.ts
import ApiService from "@/services/ApiService";
import { Session, Subscription } from "@supabase/supabase-js";
import { Store } from "nucleux";

class SessionStore extends Store {
  public session = this.atom<Session | null>(null);
  public initialized = this.atom<boolean>(false);

  private apiService = this.inject(ApiService);
  private authSubscription: Subscription;

  constructor() {
    super();

    this.getSession();

    this.authSubscription = this.apiService.apiClient.auth.onAuthStateChange(
      (_, session) => {
        this.setSession(session);
      }
    ).data.subscription;
  }

  private async getSession() {
    try {
      const { data: { session } } = await this.apiService.apiClient.auth.getSession();
      this.setSession(session);
    } finally {
      this.initialized.value = true;
    }
  }

  private setSession(session: Session | null) {
    this.session.value = session;
  }

  public async signIn(email: string, password: string) {
    return this.apiService.apiClient.auth.signInWithPassword({
      email,
      password,
    });
  }

  public async signOut() {
    return this.apiService.apiClient.auth.signOut();
  }

  destroy() {
    this.authSubscription.unsubscribe();
    super.destroy();
  }
}

export default SessionStore;

Architecture Highlights:

Dependency Injection: this.inject(ApiService) automatically provides the API client
Atomic State: Only components using session or initialized re-render when these values change
Event Handling: Supabase auth changes automatically update the atomic state
Clean API: Simple methods for sign in/out that any component can use

Building the Auth Component

Finally, create a simple authentication component that consumes the session store:

// components/Auth.tsx
import SessionStore from "@/stores/SessionStore";
import { useStore, useValue } from "nucleux";
import React, { useState } from "react";
import { Alert, StyleSheet, Text, TextInput, TouchableOpacity, View } from "react-native";

export default function Auth() {
  const sessionStore = useStore(SessionStore);
  const session = useValue(sessionStore.session);
  const initialized = useValue(sessionStore.initialized);

  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");
  const [loading, setLoading] = useState(false);

  const handleSignIn = async () => {
    if (!email || !password) {
      Alert.alert("Error", "Please fill in all fields");
      return;
    }

    setLoading(true);
    try {
      const { error } = await sessionStore.signIn(email, password);
      if (error) Alert.alert("Error", error.message);
    } finally {
      setLoading(false);
    }
  };

  const handleSignOut = async () => {
    const { error } = await sessionStore.signOut();
    if (error) Alert.alert("Error", error.message);
  };

  if (!initialized) {
    return <Text>Loading...</Text>;
  }

  if (session) {
    return (
      <View style={styles.container}>
        <Text style={styles.title}>Welcome back!</Text>
        <Text>Signed in as: {session.user.email}</Text>
        <TouchableOpacity style={styles.button} onPress={handleSignOut}>
          <Text style={styles.buttonText}>Sign Out</Text>
        </TouchableOpacity>
      </View>
    );
  }

  return (
    <View style={styles.container}>
      <Text style={styles.title}>Sign In</Text>

      <TextInput
        style={styles.input}
        placeholder="Email"
        value={email}
        onChangeText={setEmail}
        autoCapitalize="none"
        keyboardType="email-address"
      />

      <TextInput
        style={styles.input}
        placeholder="Password"
        value={password}
        onChangeText={setPassword}
        secureTextEntry
      />

      <TouchableOpacity 
        style={[styles.button, loading && styles.buttonDisabled]} 
        onPress={handleSignIn}
        disabled={loading}
      >
        <Text style={styles.buttonText}>
          {loading ? "Signing In..." : "Sign In"}
        </Text>
      </TouchableOpacity>
    </View>
  );
}

const styles = StyleSheet.create({
  container: { flex: 1, padding: 20, justifyContent: "center" },
  title: { fontSize: 24, fontWeight: "bold", marginBottom: 20, textAlign: "center" },
  input: { borderWidth: 1, borderColor: "#ddd", padding: 12, marginBottom: 10, borderRadius: 5 },
  button: { backgroundColor: "#007AFF", padding: 12, borderRadius: 5, marginTop: 10 },
  buttonDisabled: { opacity: 0.5 },
  buttonText: { color: "white", textAlign: "center", fontWeight: "bold" },
});

Why This Architecture Works

1. Clear Separation of Concerns
Each layer has a single responsibility, making the code easier to test and maintain.

2. Automatic Reactivity
Components automatically re-render when authentication state changes, without manual subscription management.

3. Reusable Business Logic
The SessionStore can be used across multiple components without duplicating authentication logic.

4. Type Safety
TypeScript ensures you catch authentication-related bugs at compile time.

5. Easy Testing
Each store can be unit tested independently of React components.

The Result

This architecture gives you a robust foundation for React Native apps that need authentication. The SessionStore becomes the single source of truth for authentication state, while the component layer focuses purely on user interface concerns.

Want to explore more patterns? Check out the complete Nucleux documentation and see how this same approach scales to complex applications with multiple data stores and API services.

Ready to build your next React Native app? Try combining Nucleux with Supabase for a powerful, type-safe development experience.

"Every Developer I Meet Is My Superior": How Emerson's Wisdom Transformed My Code Reviews

Marty Roque — Thu, 26 Jun 2025 01:12:48 +0000

"Every man I meet is in some way my superior; and in that I can learn of him."
— Ralph Waldo Emerson

When Ralph Waldo Emerson wrote these words in the 1800s, he probably wasn't thinking about code reviews. But this philosophy became my secret weapon for better software and stronger teams.

The Hierarchy Trap in Tech

The tech industry loves hierarchies. Junior, Mid-level, Senior, Staff, Principal. We wear these titles like badges, and unconsciously, they shape how we interact with each other.

I fell into this trap early. As a "senior" developer, I approached code reviews and pair programming sessions as teaching opportunities—I was there to share my wisdom with less experienced developers.

I was missing half the conversation.

Emerson's insight flipped this dynamic entirely. What if, instead of focusing on what I could teach, I approached every interaction wondering what I could learn?

The Transformation: From Teacher to Student

After that code review revelation, I started applying Emerson's principle deliberately. Here's what changed:

Before: The "Teaching" Mindset

"This component is doing too much. You should break it down into smaller components for better maintainability."

After: The "Learning" Mindset

"I notice this component handles multiple responsibilities. What was your thinking behind keeping them together? I'm curious if there's a context I'm missing that makes this approach beneficial."

The difference is subtle but profound. The first comment assumes I know the right answer. The second acknowledges that the developer might have insights I lack.

What Junior Developers Taught Me

Over the past few years, here are some surprising lessons I've learned from developers with less "experience":

1. Fresh Eyes See Old Problems Differently

A junior developer questioned why we were manually managing form state when we could use a form library. Her fresh perspective led us to adopt React Hook Form, reducing our form-related bugs.

// What I was doing (overcomplicated):
const [formData, setFormData] = useState({});
const [errors, setErrors] = useState({});
const [touched, setTouched] = useState({});
// ... 50 more lines of manual state management

// What she suggested (elegant):
const { register, handleSubmit, formState: { errors } } = useForm();
// Done.

2. Modern Solutions to Legacy Problems

Junior developers often come with knowledge of the latest tools and approaches. They haven't yet learned that "we've always done it this way."

A team member introduced our team to React Query, transforming how we handle server state. I was still writing custom hooks with useEffect and useState for every API call.

3. User-First Thinking

Less experienced developers often think more like users because they haven't been deep in the technical weeds for years. They ask questions like:

"Why does the user have to click three times for this?"
"What if someone doesn't understand this error message?"

These questions often lead to better UX decisions than my technically-focused optimization concerns.

The Socratic Code Review

Emerson's principle transformed my code review process into what I call "Socratic Code Reviews"—focused on learning through questioning rather than teaching through telling.

Traditional Code Review:

Point out issues
Suggest solutions
Approve or request changes

Socratic Code Review:

Ask about reasoning
Explore alternatives together
Learn from different perspectives

This shift in mindset led me to completely reimagine the code review process. Instead of...

// Instead of: "Use const instead of let here"
// I ask: "I see you used let here—are you planning to reassign this variable later in the function?"

// Instead of: "This function is too long"
// I ask: "This function handles several distinct operations. What do you think about the trade-offs between keeping it unified vs. splitting it up?"

// Instead of: "You should add error handling"
// I ask: "What kinds of errors do you think we might encounter here? How should the user experience those errors?"

Learning from Different Experience Levels

The Emerson principle works at every level:

From Junior Developers:

Latest tools and techniques
Fresh perspectives on old problems
User-focused thinking
Willingness to question established patterns

From Senior Developers:

Battle-tested architectural patterns
War stories about what breaks at scale
Long-term maintenance perspectives
Domain expertise

From Peer Developers:

Different problem-solving approaches
Alternative implementation strategies
Cross-domain knowledge
Different debugging techniques

The Compound Effect of Intellectual Humility

After applying Emerson's wisdom throughout my 13 years in development, I've noticed compound effects:

Better Code: Teams produce higher-quality solutions when everyone's ideas are valued
Faster Learning: I learn new techniques and tools much faster than when I relied only on senior-level resources
Stronger Teams: Psychological safety increases when people feel their insights are genuinely welcomed
Personal Growth: My technical skills have accelerated because I'm learning from 5-10 different perspectives instead of just my own

Making This Practical: Your Next Code Review

Here's how to apply Emerson's principle starting with your very next code review:

1. Replace Statements with Questions

"This could be optimized" → "What do you think about the performance implications here?"
"Use this pattern instead" → "Have you considered this alternative pattern? What are the trade-offs?"

2. Assume Positive Intent

Every code choice was made for a reason. Your job is to understand that reason before suggesting alternatives.

3. Share Your Thinking Process

"I usually approach this differently because..."
"In my experience, X tends to cause Y, but maybe that's not relevant here..."

4. Ask for Their Experience

"Have you used this pattern before? How did it work out?"
"What other approaches did you consider?"

The Paradox of Expertise

Here's what Emerson understood that took me years to learn: True expertise isn't about knowing more than everyone else. It's about learning more from everyone else.

The moment you think you're the smartest person in the room is the moment you stop growing. In software development, where technologies evolve daily and user needs constantly shift, the ability to learn from others isn't just helpful—it's essential for survival.

Your Challenge This Week

Pick one person on your team who you normally think of as "less experienced" than you. In your next interaction with them—whether it's a code review, pair programming session, or casual conversation—approach it with genuine curiosity about what they might teach you.

Ask yourself: "What does this person know that I don't?"

You might be surprised by the answer.

The best developers I know aren't the ones who have all the answers. They're the ones who ask the best questions and remain genuinely curious about other people's solutions.

What's the most surprising thing you've learned from a "junior" developer? Share your story in the comments—I'm genuinely curious to learn from your experience.

How Layered Memoization in Nucleux v1.3.0 Eliminates React's Biggest Performance Pitfall

Marty Roque — Sun, 22 Jun 2025 17:26:13 +0000

React applications slow down for one primary reason: unnecessary re-renders. You update a user's name, and suddenly your entire shopping cart re-renders. You toggle a modal, and your complex data table rebuilds itself. Sound familiar?

This cascade effect has plagued React developers for years, leading to complex optimization strategies with React.memo, useMemo, and useCallback. But what if your state management library could eliminate this problem entirely?

The Hidden Cost of State Updates

Consider this common scenario in a typical React app:

// Traditional approach - everything re-renders
function App() {
  const [user, setUser] = useState({ name: 'John', notifications: 0 })
  const [cart, setCart] = useState([])
  const [theme, setTheme] = useState('dark')

  // Changing user.name triggers re-renders in:
  // - UserProfile component
  // - Cart component (unnecessary!)
  // - ThemeToggle component (unnecessary!)

  return (
    <div>
      <UserProfile user={user} />
      <ShoppingCart cart={cart} />
      <ThemeToggle theme={theme} />
    </div>
  )
}

When user.name changes, React re-renders every component that receives any piece of this state, even if they don't use the changed data. This becomes exponentially worse as your app grows.

Atomic Updates: The First Step

Nucleux solves this with atomic state management - only components subscribed to specific atoms re-render:

class AppStore extends Store {
  user = this.atom({ name: 'John', notifications: 0 })
  cart = this.atom([])
  theme = this.atom('dark')

  updateUserName(name) {
    this.user.value = { ...this.user.value, name }
  }
}

function UserProfile() {
  const user = useValue(AppStore, 'user')
  // Only this component re-renders when user changes
}

function ShoppingCart() {
  const cart = useValue(AppStore, 'cart')
  // This NEVER re-renders when user changes
}

But even atomic updates have a subtle performance issue...

The Memoization Problem

What happens when you update a user object with the same values?

// This triggers a re-render even though nothing actually changed!
store.updateUserName('John') // Same name as before

React compares objects by reference, not content. Even if the data is identical, creating a new object triggers unnecessary updates.

Enter Layered Memoization

Nucleux v1.3.0 introduces layered memoization that intelligently prevents updates when values haven't actually changed:

Shallow Memoization (Default)

Perfect for primitive values and objects you replace entirely:

class CounterStore extends Store {
  count = this.atom(0) // Automatically uses shallow memoization

  increment() {
    this.count.value += 1 // Only updates when value actually changes
  }
}

Deep Memoization

Ideal for complex objects where you care about content, not reference:

class UserStore extends Store {
  profile = this.atom(
    { name: 'John', email: 'john@example.com', preferences: {...} },
    { memoization: { type: 'deep' } }
  )

  updateProfile(newProfile) {
    // Only re-renders if the content actually changed
    this.profile.value = newProfile
  }
}

Custom Memoization

For specialized comparison logic:

class ProductStore extends Store {
  product = this.atom(
    { id: 1, name: 'Laptop', price: 999.99, lastUpdated: Date.now() },
    {
      memoization: {
        type: 'custom',
        compare: (prev, next) => 
          prev.id === next.id && 
          prev.name === next.name && 
          prev.price === next.price
        // Ignores lastUpdated timestamp
      }
    }
  )
}

Real-World Performance Impact

Here's a before/after comparison in a typical e-commerce app:

Without Memoization:

User updates profile → 12 components re-render
Product price change → 8 components re-render
Cart item quantity update → 15 components re-render

With Layered Memoization:

User updates profile with same data → 0 components re-render
Product price change with same price → 0 components re-render
Cart update with identical items → 0 components re-render

Beyond Atoms: Memoized Derived State

Derived state benefits from memoization too:

class TodoStore extends Store {
  todos = this.atom([])
  filter = this.atom('all')

  // Won't recalculate if filtered result contains same items
  filteredTodos = this.deriveAtom(
    [this.todos, this.filter],
    (todos, filter) => todos.filter(t => t.status === filter),
    { type: 'deep' } // Compares array content, not reference
  )
}

The Bottom Line

Layered memoization transforms your React app's performance by:

Eliminating phantom updates - No re-renders when data hasn't actually changed
Optimizing derived state - Complex calculations only run when inputs truly differ
Reducing debugging complexity - Fewer unexpected re-renders to track down
Improving user experience - Smoother interactions and better responsiveness

The best part? It works automatically. Set your memoization strategy once, and Nucleux handles the intelligent comparisons behind the scenes.

Try It Yourself

Want to experience the performance difference? Check out the complete documentation to see how layered memoization can transform your React application's performance.

Nucleux v1.3.0 is available now on npm. Upgrade today and feel the difference intelligent memoization makes in your React applications.

Which atomic state library should you choose for your next React project? Quick comparison of the top contenders 👇 #ReactJS #StateManagement #WebDev

Marty Roque — Fri, 13 Jun 2025 17:57:30 +0000

Marty Roque

Jun 11 '25

Atomic State Management: Why Nucleux Stands Out from Jotai and Zustand

#webdev #react #reactnative #opensource

Comments 1

3 min read

Atomic State Management: Why Nucleux Stands Out from Jotai and Zustand

Marty Roque — Wed, 11 Jun 2025 02:45:17 +0000

State management in React has evolved dramatically. Gone are the days when Redux was your only choice for complex applications. Today's atomic state management libraries offer fine-grained reactivity, minimal boilerplate, and better performance. But which one should you choose?

The Rise of Atomic State Management

Traditional state management forces entire components to re-render when any part of the state changes. Atomic state management flips this approach - only components subscribed to specific pieces of state update when those pieces change.

This granular approach offers several key benefits:

Performance: Eliminates unnecessary re-renders
Simplicity: No complex provider trees or reducer boilerplate
Scalability: Independent state atoms that don't interfere with each other
Developer Experience: Intuitive APIs that feel natural to use

Enter Nucleux: The Best of Both Worlds

Nucleux combines the atomic precision of Jotai with the simplicity of Zustand, while adding some unique advantages:

import { Store, useNucleux } from 'nucleux'

class CounterStore extends Store {
  count = this.atom(0)
  name = this.atom('John')

  increment() {
    this.count.value += 1
  }
}

function Counter() {
  const { count, increment } = useNucleux(CounterStore)
  return <button onClick={increment}>{count}</button>
}

Why Nucleux Wins

1. True Atomic Updates, Zero Providers

Unlike Jotai, Nucleux requires no providers. Unlike Zustand, it offers genuine atomic updates - only components using count re-render when count changes, not components using name.

2. Organized State Architecture

Instead of scattered atoms or monolithic stores, Nucleux uses classes to group related state and methods logically:

class TodoStore extends Store {
  todos = this.atom([])
  filter = this.atom('all')

  // Derived state that auto-updates
  filteredTodos = this.deriveAtom(
    [this.todos, this.filter],
    (todos, filter) => todos.filter(/* filter logic */)
  )

  addTodo(text) {
    this.todos.value = [...this.todos.value, { id: Date.now(), text }]
  }
}

3. Built-in Dependency Injection

Need one store to react to another? Nucleux makes it effortless:

class NotificationStore extends Store {
  userStore = this.inject(UserStore)
  notifications = this.atom([])

  constructor() {
    super()
    // Auto-load notifications when user changes
    this.watchAtom(this.userStore.currentUser, (user) => {
      if (user) this.loadNotifications(user.id)
    })
  }
}

4. Automatic Persistence

Save state to localStorage or AsyncStorage with zero boilerplate:

class UserStore extends Store {
  // Automatically persists to localStorage
  preferences = this.atom({ theme: 'dark' }, 'user-prefs')
}

5. Three Ways to Access State

Choose the right tool for each component:

// Just the methods
const store = useStore(TodoStore)

// Single atom value
const todos = useValue(TodoStore, 'todos')

// Everything at once
const { todos, filter, addTodo } = useNucleux(TodoStore)

Performance Comparison

Feature	Jotai	Zustand	Nucleux
Atomic Updates	✅	❌	✅
No Providers	❌	✅	✅
Organized Architecture	❌	⚠️	✅
Built-in Persistence	❌	❌	✅
Dependency Injection	❌	❌	✅

The Bottom Line

While Jotai and Zustand are excellent libraries, Nucleux offers the complete package:

Atomic precision without provider complexity
Organized architecture that scales with your team
Built-in features that eliminate common boilerplate

Ready to simplify your React state management? Give Nucleux a try in your next project.

Want to see Nucleux in action? Check out the live demo or visit nucleux.dev for complete documentation.

Meet Nucleux: The state management library that actually makes React development enjoyable again. Atomic updates, zero setup, built-in persistence, and no more provider hell. See how to build a full todo app with surprisingly little code!

Marty Roque — Fri, 30 May 2025 14:59:09 +0000

Marty Roque

Apr 7 '25

Simplify Your React State Management with Nucleux

#react #javascript #nucleux #opensource

Comments

4 min read

[Boost]

Marty Roque — Fri, 30 May 2025 04:38:42 +0000

Marty Roque

May 30 '25

Building a Real Estate Search App with Nucleux: Clean Architecture Made Simple

#webdev #react #typescript #programming

Comments 3

5 min read

Building a Real Estate Search App with Nucleux: Clean Architecture Made Simple

Marty Roque — Fri, 30 May 2025 04:34:47 +0000

Real estate applications are notorious for their complexity. Between property filtering, map interactions, user preferences, and real-time updates, the state management can quickly become a tangled mess. Let's explore how Nucleux transforms this complexity into clean, maintainable TypeScript code.

The Challenge: State Management Chaos

Traditional React state management for real estate apps often leads to:

Provider hell with nested contexts for filters, properties, favorites, and map state
Prop drilling through multiple component layers
Complex useEffect chains trying to synchronize related state
Performance issues from unnecessary re-renders when any state changes

Imagine trying to coordinate updates between a property list, map markers, filter sidebar, and favorites panel using traditional Redux or Context API – the boilerplate alone would be overwhelming.

The Nucleux Approach: Atomic State Architecture

Nucleux solves these problems through atomic state management and dependency injection. Let's build a real estate search app that demonstrates four key benefits:

1. Streamlined Development: No Boilerplate, Just Logic

With Nucleux, you define your state as simple TypeScript classes:

import { Store } from 'nucleux';

interface SearchFilters {
  minPrice: number;
  maxPrice: number;
  bedrooms: number | null;
  bathrooms: number | null;
  propertyType: 'any' | 'house' | 'apartment' | 'condo';
  location: string;
}

interface SavedSearch {
  id: number;
  name: string;
  filters: SearchFilters;
}

class SearchStore extends Store {
  filters = this.atom<SearchFilters>({
    minPrice: 100000,
    maxPrice: 1000000,
    bedrooms: null,
    bathrooms: null,
    propertyType: 'any',
    location: ''
  }, 'search-filters');

  savedSearches = this.atom<SavedSearch[]>([], 'saved-searches');

  updateFilter = <K extends keyof SearchFilters>(key: K, value: SearchFilters[K]) => {
    this.filters.value = { ...this.filters.value, [key]: value };
  };

  saveCurrentSearch = (name: string) => {
    const newSearch: SavedSearch = { 
      id: Date.now(), 
      name, 
      filters: this.filters.value 
    };
    this.savedSearches.value = [...this.savedSearches.value, newSearch];
  };
}

No reducers, no action creators, no dispatch functions – just straightforward methods that update state. The 'search-filters' persistence key ensures user preferences survive browser refreshes.

2. Superior Maintainability: Clean Separation of Concerns

Each store handles a specific domain, making the codebase easier to understand and modify:

interface Property {
  id: string;
  price: number;
  bedrooms: number;
  bathrooms: number;
  type: 'house' | 'apartment' | 'condo';
  address: string;
  coordinates: {
    lat: number;
    lng: number;
  };
  imageUrl: string;
  description: string;
}

interface MapBounds {
  north: number;
  south: number;
  east: number;
  west: number;
}

class PropertiesStore extends Store {
  searchStore = this.inject(SearchStore);
  allProperties = this.atom<Property[]>([]);
  loading = this.atom<boolean>(false);
  mapBounds = this.atom<MapBounds | null>(null);

  constructor() {
    super();
    this.loadProperties();

    // Auto-refresh when filters change
    this.watchAtom(this.searchStore.filters, () => {
      this.loadProperties();
    });
  }

  filteredProperties = this.deriveAtom(
    [this.allProperties, this.searchStore.filters, this.mapBounds],
    (properties: Property[], filters: SearchFilters, bounds: MapBounds | null) => {
      return properties
        .filter(property => this.matchesFilters(property, filters))
        .filter(property => this.withinMapBounds(property, bounds));
    }
  );

  private loadProperties = async (): Promise<void> => {
    this.loading.value = true;
    try {
      const response = await fetch(
        "https://raw.githubusercontent.com/BrianQMclaren/real-estate/refs/heads/master/data.json"
      );
      const data = await response.json();
      this.allProperties.value = data.property || [];
    } catch (error) {
      console.error('Failed to load properties:', error);
      this.allProperties.value = [];
    } finally {
      this.loading.value = false;
    }
  };

  private matchesFilters = (property: Property, filters: SearchFilters): boolean => {
    const { minPrice, maxPrice, bedrooms, bathrooms, propertyType, location } = filters;

    if (property.price < minPrice || property.price > maxPrice) return false;
    if (bedrooms && property.bedrooms !== bedrooms) return false;
    if (bathrooms && property.bathrooms !== bathrooms) return false;
    if (propertyType !== 'any' && property.type !== propertyType) return false;
    if (location && !property.address.toLowerCase().includes(location.toLowerCase())) return false;

    return true;
  };

  private withinMapBounds = (property: Property, bounds: MapBounds | null): boolean => {
    if (!bounds) return true;
    const { lat, lng } = property.coordinates;
    return lat >= bounds.south && lat <= bounds.north && 
           lng >= bounds.west && lng <= bounds.east;
  };
}

Notice how PropertiesStore automatically injects SearchStore and reacts to filter changes. The derived filteredProperties atom efficiently recalculates only when its dependencies change.

3. Optimized Performance: Surgical Re-renders

Nucleux's atomic updates ensure components only re-render when their specific data changes:

class FavoritesStore extends Store {
  favorites = this.atom<string[]>([], 'favorite-properties');

  toggleFavorite = (propertyId: string): void => {
    const current = this.favorites.value;
    this.favorites.value = current.includes(propertyId)
      ? current.filter(id => id !== propertyId)
      : [...current, propertyId];
  };

  isFavorite = (propertyId: string): boolean => {
    return this.favorites.value.includes(propertyId);
  };
}

When a user favorites a property, only components displaying favorite status re-render – not the entire property list, map, or filter panel.

4. Built-in Persistence: Zero-Configuration Data Retention

User preferences automatically persist across sessions without additional setup:

import React from 'react';
import { useValue, useStore, useNucleux } from 'nucleux';

const FilterPanel: React.FC = () => {
  const searchStore = useStore(SearchStore);
  const filters = useValue(searchStore.filters);

  const handleMinPriceChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    const value = parseInt(e.target.value) || 0;
    updateFilter('minPrice', value);
  };

  const handleMaxPriceChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    const value = parseInt(e.target.value) || 0;
    updateFilter('maxPrice', value);
  };

  const handleBedroomsChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    const value = e.target.value ? parseInt(e.target.value) : null;
    updateFilter('bedrooms', value);
  };

  return (
    <div className="filter-panel" style={{ padding: '20px', border: '1px solid #ccc', borderRadius: '8px' }}>
      <h3>Search Filters</h3>

      <div style={{ marginBottom: '15px' }}>
        <label>
          Min Price: $
          <input
            type="number"
            value={filters.minPrice}
            onChange={handleMinPriceChange}
            style={{ marginLeft: '5px', padding: '5px', width: '120px' }}
          />
        </label>
      </div>

      <div style={{ marginBottom: '15px' }}>
        <label>
          Max Price: $
          <input
            type="number"
            value={filters.maxPrice}
            onChange={handleMaxPriceChange}
            style={{ marginLeft: '5px', padding: '5px', width: '120px' }}
          />
        </label>
      </div>

      <div style={{ marginBottom: '15px' }}>
        <label>
          Bedrooms:
          <input
            type="number"
            value={filters.bedrooms || ''}
            onChange={handleBedroomsChange}
            placeholder="Any"
            min="1"
            max="10"
            style={{ marginLeft: '5px', padding: '5px', width: '80px' }}
          />
        </label>
      </div>

      <div style={{ marginBottom: '15px' }}>
        <label>
          Location:
          <input
            type="text"
            value={filters.location}
            onChange={(e) => updateFilter('location', e.target.value)}
            placeholder="Enter city or address"
            style={{ marginLeft: '5px', padding: '5px', width: '200px' }}
          />
        </label>
      </div>
    </div>
  );
};

const PropertyList: React.FC = () => {
  const properties = useValue(PropertiesStore, 'filteredProperties');
  const loading = useValue(PropertiesStore, 'loading');

  if (loading) return <div>Loading properties...</div>;

  return (
    <div className="property-list">
      <h3>Properties ({properties.length} found)</h3>
      {properties.map(property => (
        <PropertyCard key={property.id} property={property} />
      ))}
    </div>
  );
};

const PropertyCard: React.FC<{ property: Property }> = ({ property }) => {
  const { toggleFavorite, isFavorite } = useNucleux(FavoritesStore);
  const favorited = isFavorite(property.id);

  return (
    <div style={{ 
      border: '1px solid #ddd', 
      borderRadius: '8px', 
      padding: '15px', 
      marginBottom: '15px',
      backgroundColor: '#f9f9f9'
    }}>
      <div style={{ display: 'flex', justifyContent: 'space-between', alignItems: 'start' }}>
        <div>
          <h4>${property.price.toLocaleString()}</h4>
          <p>{property.bedrooms} bed, {property.bathrooms} bath {property.type}</p>
          <p>{property.address}</p>
          <p style={{ color: '#666', fontSize: '14px' }}>{property.description}</p>
        </div>
        <button 
          onClick={() => toggleFavorite(property.id)}
          style={{ 
            background: favorited ? '#ff4444' : '#ddd',
            color: favorited ? 'white' : 'black',
            border: 'none',
            padding: '5px 10px',
            borderRadius: '4px',
            cursor: 'pointer'
          }}
        >
          {favorited ? '♥ Favorited' : '♡ Favorite'}
        </button>
      </div>
    </div>
  );
};

The Result: Code That Scales

This TypeScript architecture delivers remarkable benefits:

No provider hell: Import and use stores directly in any component
Automatic optimization: Components re-render only when their data changes
Intuitive debugging: State lives in predictable class instances
Easy testing: Mock store methods like any other class
Flexible persistence: User preferences survive refreshes automatically
Type safety: Full TypeScript support with intelligent autocomplete

Conclusion

Real estate applications don't have to be complex. With Nucleux's atomic state management and TypeScript support, you can build feature-rich property search experiences while maintaining clean, type-safe, understandable code.

The combination of streamlined development, superior maintainability, optimized performance, and built-in persistence makes Nucleux particularly powerful for data-heavy applications like real estate platforms.

Ready to simplify your next React project? Try Nucleux and experience state management the way it should be.

Want to see this in action? Check out the live demo and explore the GitHub repository.

Introducing Nucleux: A refreshingly simple atomic state management for React with zero boilerplate. Build a complete todo app in minutes, enjoy automatic isolated updates, and forget about providers. Simplify your next project! #ReactJS #StateManagement

Marty Roque — Mon, 07 Apr 2025 00:57:58 +0000

Marty Roque

Apr 7 '25

Simplify Your React State Management with Nucleux

#react #javascript #nucleux #opensource

Comments

4 min read

Simplify Your React State Management with Nucleux

Marty Roque — Mon, 07 Apr 2025 00:52:41 +0000

When an application's complexity grows beyond what local component state can handle, we need a state management solution that fits our architecture and allows our application to scale while preserving code readability.

While Redux provides good scalability, it comes with too much boilerplate code. This created opportunities for simpler alternatives like Recoil, Zustand, and Jōtai to gain popularity. Today, I'm excited to introduce Nucleux - an evolution of App's Digest that provides a refreshingly simple approach to state management.

What is Nucleux?

Nucleux is a simple, atomic state management library based on the publisher-subscriber pattern and inversion-of-control (IoC) container design. Unlike Redux and Zustand where data is stored in global storage outside the component tree, Nucleux stores data in centralized locations called stores, with atomic units of state that your application can subscribe to.

Nucleux only triggers strictly-needed, isolated updates for components subscribed to specific atoms - all without creating numerous providers or using derived state selectors. Instead, Nucleux gives you access to particular state anywhere in your application.

Note: Nucleux is the evolution of App's Digest, refined based on developer feedback with an improved API and new features while maintaining the core principles of simplicity and atomic updates.

Building a Todo App with Nucleux

Let's build a simple but practical todo application to see Nucleux in action.

Step 1: Installation

First, install Nucleux:

npm install nucleux
# or
yarn add nucleux

Step 2: Create Your Todo Store

Let's create a TodoStore that will manage our todo items:

// TodoStore.js
import { Store } from 'nucleux';
import { nanoid } from 'nanoid';

class TodoStore extends Store {
  // Define our atoms (state)
  todos = this.atom([], 'todos'); // The second parameter enables persistence

  // Add a todo
  addTodo(text) {
    const currentTodos = this.todos.value;

    this.todos.value = [
      ...currentTodos,
      {
        id: nanoid(),
        text,
        completed: false,
        createdAt: Date.now()
      }
    ];
  }

  // Toggle a todo's completion status
  toggleTodo(id) {
    const currentTodos = this.todos.value;
    this.todos.value = currentTodos.map(todo => 
      todo.id === id ? { ...todo, completed: !todo.completed } : todo
    );
  }

  // Update todo text
  updateTodo(id, text) {
    const currentTodos = this.todos.value;
    this.todos.value = currentTodos.map(todo => 
      todo.id === id ? { ...todo, text } : todo
    );
  }

  // Remove a todo
  removeTodo(id) {
    const currentTodos = this.todos.value;
    this.todos.value = currentTodos.filter(todo => todo.id !== id);
  }

  // Create a derived atom for ordered todos
  orderedTodos = this.deriveAtom(
    [this.todos],
    (todos) => {
      return [...todos].sort((a, b) => (a.createdAt > b.createdAt ? 1 : -1));
    }
  );
}

export default TodoStore;

Step 3: Create React Components

Now, let's create our React components:

// TodoAdd.jsx
import React, { useState } from 'react';
import { useStore } from 'nucleux';
import TodoStore from './TodoStore';

const TodoAdd = () => {
  const todoStore = useStore(TodoStore);
  const [value, setValue] = useState("");

  const onInputChange = (e) => {
    setValue(e.target.value);
  };

  const onAddClick = () => {
    if (value) {
      todoStore.addTodo(value);
      setValue("");
    }
  };

  return (
    <div>
      <input 
        placeholder="New Todo"
        value={value} 
        onChange={onInputChange}
      />
      <button onClick={onAddClick}>Add</button>
    </div>
  );
};

// TodoItem.jsx
import React from 'react';
import { useStore } from 'nucleux';
import TodoStore from './TodoStore';

const TodoItem = ({ id, text, completed }) => {
  const todoStore = useStore(TodoStore);

  const onCheckboxChange = () => {
    todoStore.toggleTodo(id);
  };

  const onInputChange = (e) => {
    todoStore.updateTodo(id, e.target.value);
  };

  const onDeleteClick = () => {
    todoStore.removeTodo(id);
  };

  return (
    <div>
      <input 
        type="checkbox" 
        checked={completed} 
        onChange={onCheckboxChange} 
      />
      <input value={text} onChange={onInputChange} />
      <button onClick={onDeleteClick}>Delete</button>
    </div>
  );
};

// TodoList.jsx
import React from 'react';
import { useStore, useValue } from 'nucleux';
import TodoStore from './TodoStore';
import TodoItem from './TodoItem';

const TodoList = () => {
  const todoStore = useStore(TodoStore);
  const todos = useValue(todoStore.orderedTodos);

  return (
    <div>
      {todos.map((todo) => (
        <TodoItem key={todo.id} {...todo} />
      ))}
    </div>
  );
};

// App.jsx
import React from 'react';
import TodoAdd from './TodoAdd';
import TodoList from './TodoList';

const App = () => {
  return (
    <div className="App">
      <h1>State Management with Nucleux</h1>
      <h2>My TODO list</h2>
      <TodoList />
      <TodoAdd />
    </div>
  );
};

export default App;

Step 4: That's it!

Yes, it's that simple! No additional setup, no wrapping your app in providers, no complex configuration.

What Makes Nucleux Different?

1. Minimal Boilerplate

Compare the code we wrote with Redux or even Context API with reducers:

No action creators
No reducers
No dispatch functions
No providers wrapping your app

2. Atomic Updates

Nucleux only updates components that are specifically subscribed to the atoms that change. If you have a complex UI with many components, only those that use the changed atoms would re-render - not the entire component tree.

3. Derived Atoms Made Simple

The orderedTodos derived atom automatically updates when the todos atom changes. This computation happens outside your components, keeping them clean and focused on presentation.

4. Built-in Persistence

By simply passing a string ID to the atom (this.atom([], 'todos')), we get persistence for free.

5. Dependency Injection

While not shown in this example, Nucleux lets you inject dependencies between stores using the this.inject() method - a powerful feature for larger applications.

From App's Digest to Nucleux: The Evolution

Nucleux builds on the foundation laid by App's Digest with improvements:

More intuitive API (todos.value instead of todos.publish())
Enhanced dependency injection through IoC container
Expanded hook support with improved lifecycle management
Better TypeScript support
Smaller bundle size
Enhanced performance optimizations

Conclusion

Nucleux provides a refreshingly simple approach to state management while offering the power needed for complex applications. The publisher-subscriber pattern and IoC container design principles enable clean architecture without the typical complexity.

Give Nucleux a try in your next project:

What state management challenges have you faced that Nucleux might solve? Let me know in the comments!

Data fetching in React using App's Digest

Marty Roque — Sat, 18 Feb 2023 03:09:34 +0000

Fetching data in react components can be done in multiple ways; unfortunately some of those are hard to maintain and debug. Let's review a common one.

The `useEffect` nightmare

The usual convention is to use the useEffect to trigger a fetch, to then set the data in a local state.

const DataComponent = () => {
  const [data, setData] = useState(null);

  useEffect(() => {
    const fetchData = async () => {
      const response = await fetch(`https://swapi.dev/api/people/1/`);
      const newData = await response.json();
      setData(newData);
    };

    fetchData();
  }, []);

  return data && <div>{data.name}</div>;
}

This data is only available in this component. If we need to access this data from any other component we'd need to setup some form of context, prop-drilling or state management.

There's also the risk of causing the useEffect to re-run more often than needed (read more about the useEffect caveats).

A new hope

With the state management approach in mind, let's review another way to fetch data using App's Digest.

Setting up our store

Let's create a new file within our project src/stores/DataStore.js. And let's put in place the basic store setup.

import { AppsDigestValue } from "apps-digest";

class DataStore {
  data = new AppsDigestValue(null);
}

export default DataStore;

Adding a fetching method

Let's create an async method called fetchData, which will do the same fetching call we saw in the useEffect example. And in order to set the state, we can just publish the new data from our data state atom.

class DataStore {
  data = new AppsDigestValue(null);

  async fetchData() {
    const response = await fetch(`https://swapi.dev/api/people/1/`);
    const newData = await response.json();

    this.data.publish(newData);
  }
}

Trigger our fetching from our constructor

Now, we want to make sure that everytime our store is loaded, the data that it needs is fetched. We can achieve this by calling our new method from the constructor

class DataStore {
  data = new AppsDigestValue(null);

  constructor() {
    this.fetchData();
  }

  async fetchData() {...}
}

Use our new store in our component

Now let's use our store in our component and see the data loading. We will consume our store via useAppsDigestStore hook, which will load our store into memory so we can access our data state atom via useAppsDigestValue.

import { useAppsDigestStore, useAppsDigestValue } from "apps-digest";
import DataStore from "./stores/DataStore";

const DataComponent = () => {
  const dataStore = useAppsDigestStore(DataStore);
  const data = useAppsDigestValue(dataStore.data);

  return <div>{data === null ? "Loading..." : data.name}</div>;
};

And voilà! Our data is loaded!

With this approach we can delegate the data fetching to our store and keep our components clean. This keeps our business logic separate, which is easier to test, maintain and debug.

DEV Community: Marty Roque

How I Removed Redux Toolkit From My React Native App

The Redux Toolkit Tax

What I Actually Needed

Using It In Components

The Re-Render Win

Dependency Injection Without Context

The Expo Router Reality

What About Persistence?

The Migration Path

What I Learned

The Results

Why This Worked For Me

Try It Yourself

Building Scalable React Native Apps with Nucleux and Supabase

The Architecture Pattern

Setting Up the API Service

Creating the Session Store

Building the Auth Component

Why This Architecture Works

The Result

"Every Developer I Meet Is My Superior": How Emerson's Wisdom Transformed My Code Reviews

The Hierarchy Trap in Tech

The Transformation: From Teacher to Student

Before: The "Teaching" Mindset

After: The "Learning" Mindset

What Junior Developers Taught Me

1. Fresh Eyes See Old Problems Differently

2. Modern Solutions to Legacy Problems

3. User-First Thinking

The Socratic Code Review

Traditional Code Review:

Socratic Code Review:

Learning from Different Experience Levels

From Junior Developers:

From Senior Developers:

From Peer Developers:

The Compound Effect of Intellectual Humility

Making This Practical: Your Next Code Review

1. Replace Statements with Questions

2. Assume Positive Intent

3. Share Your Thinking Process

4. Ask for Their Experience

The Paradox of Expertise

Your Challenge This Week

How Layered Memoization in Nucleux v1.3.0 Eliminates React's Biggest Performance Pitfall

The Hidden Cost of State Updates

Atomic Updates: The First Step

The Memoization Problem

Enter Layered Memoization

Shallow Memoization (Default)

Deep Memoization

Custom Memoization

Real-World Performance Impact

Beyond Atoms: Memoized Derived State

The Bottom Line

Try It Yourself

Which atomic state library should you choose for your next React project? Quick comparison of the top contenders 👇 #ReactJS #StateManagement #WebDev

Atomic State Management: Why Nucleux Stands Out from Jotai and Zustand

Atomic State Management: Why Nucleux Stands Out from Jotai and Zustand

The Rise of Atomic State Management

Popular Solutions: Jotai and Zustand

Jotai: Bottom-Up Atomic Approach

Zustand: Simple Global Store

Enter Nucleux: The Best of Both Worlds

Why Nucleux Wins

1. True Atomic Updates, Zero Providers

2. Organized State Architecture

3. Built-in Dependency Injection

4. Automatic Persistence

5. Three Ways to Access State

Performance Comparison

The Bottom Line

Meet Nucleux: The state management library that actually makes React development enjoyable again. Atomic updates, zero setup, built-in persistence, and no more provider hell. See how to build a full todo app with surprisingly little code!

Simplify Your React State Management with Nucleux

[Boost]

Building a Real Estate Search App with Nucleux: Clean Architecture Made Simple

Building a Real Estate Search App with Nucleux: Clean Architecture Made Simple

The Challenge: State Management Chaos

The Nucleux Approach: Atomic State Architecture

The `useEffect` nightmare