DEV Community: Israel Michael

Ilere: Building a Transparent Rental Marketplace on Expo and Supabase

Israel Michael — Thu, 09 Apr 2026 01:25:02 +0000

Ilere is a mobile housing marketplace aimed at Nigerian cities such as Ibadan, Lagos, Abuja, and Port Harcourt. The core idea is visible in the code: tenants browse listings with explicit fee breakdowns, open a listing to competitive bids from agents, choose the best offer, and continue the conversation in-app. The real problem is not just discovery. It is making the opaque part of the rental market, especially agent pricing and coordination, visible enough to compare.

The current codebase also goes beyond that loop. Tenants can save homes, contact landlord listings directly, receive in-app and push notifications, and report or block abusive users. Agents and landlords can post listings. The result is a fairly opinionated mobile product with real workflow boundaries baked into both the frontend and the database.

The architecture is straightforward in a good way. src/app/_layout.tsx is the actual shell of the app: it loads fonts, holds a shared QueryClient, hydrates auth state through authService.getCurrentUser(), subscribes to auth changes, registers notification handlers, and mounts the toast host. Navigation is file-based with Expo Router under src/app, so route structure and product structure mostly line up. The route groups are meaningful: (auth) for onboarding and sign-in, (tabs) for the primary app shell, and detail routes like house/[id].tsx, request/[id]/bids.tsx, and chat/[id].tsx for deeper flows.

State management is intentionally split. Global client state is almost nonexistent. src/features/auth/store.ts uses Zustand only for the user object plus two flags: isLoading and isResettingPassword. Everything else is treated as server state and lives in React Query. That is the right call for this app. Houses, requests, bids, chats, messages, notifications, and saved homes all originate in Supabase and often change underneath the client because of realtime subscriptions, so keeping them in a client store would have created unnecessary duplication.

The API layer follows a clean pattern: screens call feature hooks, hooks call service modules in src/services/supabase/*, and the service modules own the actual Supabase queries. src/services/supabase/client.ts sets up the typed Supabase client and persists auth in AsyncStorage:

export const supabase = createClient<Database>(supabaseUrl, supabaseAnonKey, {
  auth: {
    storage: AsyncStorage,
    autoRefreshToken: true,
    persistSession: true,
    detectSessionInUrl: false,
  },
});

That separation pays off because most interesting behavior is not a plain fetch. The service layer uses relational selects heavily. housesService.getHouses() joins house_photos and the posting user in one round trip, while src/services/supabase/chat.ts loads both participants plus recent messages and derives last_message and unread_count on the client. Supabase is acting less like a raw database client and more like a backend query surface.

One small but telling implementation detail is in authService.onAuthStateChange() inside src/services/supabase/auth.ts. The callback intentionally stays synchronous and defers follow-up work with setTimeout:

return supabase.auth.onAuthStateChange((event, session) => {
  // ...
  setTimeout(async () => {
    const { data, error } = await supabase
      .from("users")
      .select("*")
      .eq("id", userId)
      .single();
    // ...
  }, 0);
});

That is a pragmatic workaround for Supabase’s warning about deadlocks when auth state handlers call back into Supabase synchronously.

The listing feed shows a similar level of defensive implementation. housesService.getHouses() in src/services/supabase/houses.ts sanitizes the free-text query before building a PostgREST .or(...) filter:

function sanitizeSearchTerm(input: string) {
  return input
    .trim()
    .replace(/\s+/g, " ")
    .replace(/[^a-zA-Z0-9\s-]/g, " ")
    .replace(/\s+/g, " ")
    .trim() || undefined;
}

That is paired with search debouncing in src/app/(tabs)/index.tsx, where the home screen uses useDebounce(search, 350) before pushing the query into filters. Combined with useInfiniteQuery in src/features/houses/hooks/useHouses.ts, the feed avoids hammering the backend while still feeling responsive.

The most interesting data flow starts when a tenant opens a listing to bids. In src/app/house/[id].tsx, the screen computes fee breakdowns locally with housesService.getFeeBreakdown(), checks whether the listing is direct-contact-only for landlords, and uses useCreateRequest() to open a request. That mutation lands in requestsService.createRequest() in src/services/supabase/requests.ts, which checks availability, rejects landlord listings for the bidding flow, guards against duplicate active requests, and tolerates a race by refetching if the database unique constraint trips.

Selecting a winning bid is another good example of business logic spread across layers. requestsService.selectBid() updates the request, marks the chosen bid as accepted, fetches the winning agent, and then calls chatService.createChat(tenantId, bid.agent_id, requestId). The product transition from “marketplace negotiation” to “ongoing conversation” is explicit in the code.

Chat is the richest part of the frontend. src/features/chat/hooks/useChat.ts combines realtime subscriptions with optimistic updates. useSendMessage() inserts an optimistic message immediately, replaces it with the server-confirmed message on success, and removes it on error. The reconciliation is simple and effective:

const optimistic: Message = {
  id: `optimistic-${Date.now()}`,
  chat_id: chatId,
  sender_id: user!.id,
  message: payload.message,
  message_type: payload.messageType,
  data: payload.data,
  read: false,
  created_at: new Date().toISOString(),
};

src/app/chat/[id].tsx pushes the conversation model further by supporting message_type: "house_context". If a chat starts from a listing or from a selected request, the screen can seed a structured property card into the first message. That gives both sides shared context without relying on free-text recall. The logic normalizes payloads, deduplicates seeded context, groups messages by date, and coordinates moderation state.

On the backend side, Supabase is doing real work. supabase/migrations/001_initial.sql defines the base schema, indexes, RLS policies, triggers, and realtime publication. That file alone shows the actual trust model: users can read public entities like houses and profiles, but writes are scoped tightly by auth.uid(). 033_chat_moderation.sql adds user_blocks, user_reports, and a trigger that rejects message inserts for blocked pairs. Notification behavior is also database-driven. New bids and messages create notifications rows through triggers, and later migrations add push fanout and city-based new-listing alerts. The Edge Function in supabase/functions/push-notify/index.ts is intentionally thin; Postgres decides when something should notify, and the function just forwards payloads to Expo.

There are also several practical performance and UX details worth calling out. Saved homes use optimistic cache updates in src/features/houses/hooks/useSavedHomes.ts. Media uploads in src/app/post-house/index.tsx are capped using MAX_PHOTO_SIZE_BYTES and MAX_VIDEO_SIZE_BYTES from src/services/supabase/storage.ts. Notification display is route-aware in notificationService, which suppresses foreground message alerts when the user is already in /inbox or /chat/.... Safe-area handling and keyboard avoidance are consistently applied across the app shell, tabs, posting flow, and chat UI.

If I were evolving this codebase, I would not rewrite the stack. Expo Router, React Query, Zustand-for-auth-only, and Supabase are a coherent fit. The bigger opportunity is consolidation. Query key conventions are a bit thin and partially duplicated. Some business rules live in services, some in screens, and some in SQL triggers, which is workable but makes invariants harder to audit. Storage uploads currently read whole files as base64 before upload, which is simple but not memory-friendly for larger media. Tooling could also be tightened; local expo lint was inconclusive here because it tried to auto-configure ESLint and fetch network metadata rather than running against a committed project config. Those are normal next-step problems for an app that already has a real product shape.

Inside Tabs: A Practical Next.js Frontend for Multi-Business Inventory Operations

Israel Michael — Thu, 09 Apr 2026 01:16:34 +0000

Tabs is a multi-tenant operations frontend built with Next.js App Router. At a product level, it is trying to keep the daily workflow of a small or midsize business in one place: products, stores, orders, transfers, customers, people, and roles all live under the same business-scoped UI. You can see that shape directly in the route tree under app/(authenticated)/[slug], where the slug identifies the active business, and in components/home/business-list.tsx, which acts as the switchboard for choosing which business workspace to open.

That matters because the problem Tabs is solving is not just inventory tracking. It is reducing the operational overhead of hopping between separate systems for stock, staff access, customer records, and order fulfilment. The codebase reflects that ambition. It is broad, form-heavy, and biased toward shipping CRUD workflows quickly.

The application shell is layered in a way that makes that scope manageable. app/layout.tsx owns global metadata, fonts, and the top-level provider composition. components/providers/providers.tsx then stacks ContextProvider, ThemeProvider, TooltipProvider, QueryProvider, and KeyboardCommandsProvider in a single place. The authenticated shell in app/(authenticated)/layout.tsx adds TopNav, sidebar state, and the scroll container. Finally, app/(authenticated)/[slug]/layout.tsx introduces the actual business workspace with DesktopSidebar, DashboardContent, and ScrollToTop.

One of the better decisions here is that business context is inferred rather than threaded manually. components/providers/business-provider.tsx reads usePathname(), strips out known non-business routes like settings and create-business, and exposes business_slug through context. That means components deeper in the tree can call useBusiness() and build business-scoped queries without prop-drilling the slug through every intermediate layout and card.

The data access layer is similarly pragmatic. Each domain gets a thin service module in services/*.service.ts, while services/_http.service.ts holds the Axios instance, the tbs-user-sid request interceptor, and the 401 response handling that calls logout() and shows a toast. It is not a rich domain layer; it is intentionally light. Most of the orchestration lives in the client components. That tradeoff shows up everywhere: thin service modules, fat screen components.

React Query is wrapped in hooks/use-query-resource.ts so the app consumes a smaller API than raw TanStack Query. The hook is doing a few jobs at once: standardizing toasts, exposing onSuccess and onError, and invalidating related queries after mutations.

export const useModifyResource = <T>(options: MutationOptionsProps<T>) => {
  const { key, fn, onSuccess, onError, invalidateKeys, ...mutationOptions } = options;
  const queryClient = useQueryClient();

  return useMutation({
    ...mutationOptions,
    mutationFn: fn,
    onSuccess: (data) => {
      if (onSuccess) onSuccess(data);
      if (invalidateKeys?.length) {
        invalidateKeys.forEach((queryKey) => {
          queryClient.invalidateQueries({ queryKey });
        });
      }
    },
  });
};

That wrapper is useful because most screens follow the same pattern: fetch with useGetResource, mutate with useModifyResource, and let invalidation refresh the table or detail view. The tradeoff is that the wrapper becomes part of the application architecture, so mistakes inside it spread widely. One example is components/providers/query-provider.tsx, which instantiates new QueryClient() directly inside the component body. In practice that risks rebuilding the cache more often than intended.

The roles feature is a good example of translating UI state into API state without overengineering it. In app/(authenticated)/[slug]/roles/_components/roles-content.tsx, the UI groups permissions by category such as customers or stores, but the backend expects normalized strings like customer:view or location:remove. The component handles both directions locally:

const flattenPermissions = (permissions: Record<string, string[]>) => {
  const list: string[] = [];
  Object.entries(permissions).forEach(([category, actions]) => {
    const resource = categoryToResource[category] || category;
    actions.forEach((action) => {
      list.push(`${resource}:${actionToPermission[action] || action}`);
    });
  });
  return [...new Set(list)];
};

There is a matching toGroupedPermissions() for the reverse mapping when loading role details. It is a small but honest piece of application logic: the backend permission model is cleaner than the UI model, so the frontend adapts. RoleDialog and RoleSheet stay mostly focused on presentation because RolesContent owns the transformations and the fetch/mutate flow.

The most complex implementation is probably the order creation flow, especially app/(authenticated)/[slug]/orders/create-order/_components/step-4-product-details.tsx. That final step handles product selection, quantity changes, VAT toggling, derived totals, optional customer creation, and order submission in one component. It is a lot of responsibility, but it also shows the project's bias: keep the workflow close to the UI that owns it. The handleSubmit path is especially telling. It first tries to reuse an existing customer, then conditionally creates one, then builds the order payload and redirects to the new order. That is not the most layered design, but it is direct and easy to trace while debugging.

Forms across the app follow a consistent stack: react-hook-form, zodResolver, and component-local orchestration. app/(authenticated)/[slug]/products/_components/product-form.tsx is representative. It combines useForm, useFieldArray, useGetResource, useModifyResource, and a preview sidebar to support both create and edit flows. The result is a fairly capable form without introducing a separate state machine library. The downside is that these large client components are becoming maintenance hotspots, because validation, loading, transformation, side effects, and UI are often sitting in the same file.

The request flow is straightforward. components/auth/login/login-form.tsx calls signIn(), extracts tbs-user-sid, and stores it with js-cookie. middleware.ts uses the presence of that cookie to gate authenticated routes and redirect to /login when needed. After that, services/_http.service.ts injects the same cookie into outgoing requests. Screen components call useGetResource and useModifyResource, then move the results into local state or occasionally global context. components/dashboard/navbar/user-nav.tsx, for example, fetches the profile and copies it into ContextProvider so hooks like usePermissions() can read the active user object.

State is split in a sensible, lightweight way. Server state lives mostly in React Query. Form state lives in react-hook-form and useFieldArray. View state such as dialog visibility or selected rows sits in useState. App-global state is minimal: components/providers/context.tsx stores the current user and geolocated country, and components/providers/sidebar-provider.tsx stores collapsed sidebar state in localStorage.

There are also a few solid cross-cutting concerns. Performance-wise, the app enables PWA support in next.config.mjs, serves an offline fallback from app/~offline/page.tsx, and uses LazyMotion in components/shared/animated-components.tsx to avoid paying for more animation runtime than needed. components/shared/data-table/index.tsx centralizes table behavior and can operate in either client or server pagination mode, which is a good fit for admin-style screens.

Security and accessibility are mixed in the way many real products are. On the positive side, middleware.ts centralizes navigation protection, and the Axios interceptor handles expired sessions consistently. On the less comfortable side, the base API URL in services/_http.service.ts is hard-coded to an ngrok endpoint, session handling is done in client JavaScript rather than server-managed cookies, and hooks/use-permissions.ts currently allows all actions when no permissions are present. That last choice may be convenient during integration, but it is a dangerous default. Accessibility is stronger: the app gets a good baseline from Radix and shadcn primitives in components/ui, and that shows up in labeled forms, dialogs, sheets, dropdown menus, and keyboard shortcuts.

If I were continuing this codebase, I would keep the route-scoped multi-tenancy, the thin service modules, and the reusable UI primitives. They are helping the team move. I would change the infrastructure around them: stabilize the QueryClient, move auth toward server-managed cookies, replace hard-coded environment values, tighten the permissions fallback, and gradually extract orchestration out of the largest client components. Tabs already has the right product surface area for an operations app. The next step is making the implementation as durable as the workflows it is trying to support.

Inside Emoney profit tracker: a pragmatic Next.js app for reseller operations

Israel Michael — Thu, 09 Apr 2026 00:53:24 +0000

emoney-profit-tracker is a small operational app for a reseller workflow. It tracks purchased products, completed sales, profit trends over time, and a lightweight "quests" system for recurring tasks. The problem it solves is familiar: once buying, listing, shipping, and bookkeeping are spread across different tools, it becomes hard to answer basic questions like "what is actually making money?" and "what still needs attention?"

This codebase answers that with a single Next.js 15 App Router application. It is not trying to be a heavily server-rendered product. Most of the interesting work happens on the client: auth checks, data fetching, table filtering, form state, and mutation flows. That makes the app easy to reason about for dashboard-style work, even if it leaves some server-side capabilities unused.

Architecture and the shape of the app

The project is organised around App Router route groups plus feature-specific client components. app/layout.tsx defines the global shell, metadata, Providers, and the Toaster. The authenticated area lives under app/(aunthenticated), with app/(aunthenticated)/layout.tsx layering TopNav and MobileNavigation around the page body. Individual screens mostly render thin route files that hand off to client components like DashboardClient, ProductsClient, and QuestsClient.

That split works well here. Route files stay small, while screen logic sits close to the UI that owns it.

The service layer is intentionally thin. Files like services/product.service.ts, services/sales.service.ts, and services/quests.service.ts mostly expose small functions that call a shared Axios client from services/_http.service.ts. That shared client sets a fixed baseURL, enables withCredentials, and centralises 401 handling and network-error toasts:

api.interceptors.response.use(
  (response) => response,
  (error) => {
    if (error.response && error.response.status === 401) {
      if (typeof window !== "undefined") {
        const currentPath = window.location.pathname
        sessionStorage.setItem("callbackPath", currentPath)
        window.location.href = "/login"
      }
    }
    return Promise.reject(error)
  }
)

That keeps auth-expiry handling out of page components.

Data flow and state management

Remote state is handled with React Query, wrapped by lib/hooks/use-query-resource.ts. The wrappers are simple but useful: useGetResource standardises query execution and callback handling, while useModifyResource and useDeleteResource invalidate a provided query key after mutation.

return useMutation({
  ...mutationOptions,
  mutationFn: fn,
  onSuccess: (data) => {
    if (onSuccess) onSuccess(data)
    queryClient.invalidateQueries({ queryKey: key })
  },
})

That pattern shows up almost everywhere. ProductsClient fetches a list with useGetResource({ fn: getProducts, key: ["products"] }). The product table's delete action uses useModifyResource with the same key so the list refreshes without manual cache bookkeeping.

Local UI state is kept local. Search input, selected tabs, dialog visibility, selected files, and transient submission state all live in component state rather than being pushed into a global store. Forms use React Hook Form and Zod, which is the right fit here: field registration stays cheap, validation is explicit, and submit handlers can sanitize outgoing payloads before mutation.

Authentication is also managed on the client in components/providers/auth-context.tsx. AuthProvider stores the current user and an authStatus, while AuthGuard calls getUser() once on mount, redirects unauthenticated users to /login, and preserves the intended path in sessionStorage. The login button in app/login/components/login-button.tsx builds a Discord OAuth URL that uses that saved path as state.

This is centralized and easy to follow, but it is also fully client-side. Protected routes are redirected after hydration rather than being rejected earlier by middleware or server components.

Interesting implementation details

One of the better pieces of UI logic is in app/(aunthenticated)/sales/add-sale/_components/add-sale-form.tsx. The form does more than collect fields. It debounces product lookup with useDebounce, loads matching products through productsLookup, and adjusts validation based on the selected product's stock level:

const createDynamicSchema = (maxQuantity?: number) => {
  return z.object({
    quantity: maxQuantity
      ? z.number().min(1).max(maxQuantity, `Quantity cannot exceed ${maxQuantity}`)
      : z.number().min(1),
  })
}

When a product is selected, the form also pre-fills sale_price from purchase_price and clamps quantity if it exceeds stock. That is a good example of business rules living in the form layer.

Another strong detail is the quest proof submission flow in app/(aunthenticated)/quests/_components/quests-proof-submission.tsx. The same form renders as a Dialog on desktop and a Drawer on mobile using useIsMobile(450). The upload side is handled by components/shared/file-uploader.tsx, which uses react-dropzone, generates preview URLs with URL.createObjectURL, and passes real File objects into a FormData payload.

The shared table in components/shared/data-table/index.tsx is another important building block. It standardises sorting, filtering, pagination, loading skeletons, empty states, and "add new" actions on top of TanStack Table. That keeps SalesClient and ProductsClient small.

There are also a few rough edges worth calling out, honestly. The QueryClient is instantiated inside the Providers component on every render:

const Providers: React.FC<React.PropsWithChildren> = ({ children }) => {
  const queryClient = new QueryClient()
  return <QueryClientProvider client={queryClient}>{children}</QueryClientProvider>
}

That risks resetting cache state if the provider re-renders. It would be safer to memoize it or create it once outside the component.

There are also some endpoint mismatches that look like copy-paste drift. In the sales edit flow, app/(aunthenticated)/sales/edit-sale/[slug]/page.tsx calls getSingleProduct, and the sale form's edit path uses updateProduct. Likewise, some delete actions for sales and recent transactions call deleteProduct.

The admin area is another revealing detail. app/(aunthenticated)/control/admin/_components/admin-client.tsx is visually fleshed out, but its metrics are currently static. Compared with the sales, products, and quests flows, it reads more like a dashboard stub than a finished screen.

Performance, security, and accessibility

Performance work here is practical rather than exotic. The app debounces product lookup, uses React Query caching and invalidation to avoid redundant fetch bookkeeping, and leans on next/image through components/shared/image-loader.tsx for product imagery.

Security is mostly about session handling. Axios requests are sent with credentials, 401s are intercepted centrally, and the login flow preserves the callback path through OAuth state. What is missing is stronger server-side enforcement in the frontend layer; because auth is client-guarded, a lot of route protection depends on hydration-time redirects rather than server rejection.

Accessibility is mixed but generally thoughtful. Many controls come from Radix-based UI primitives, which is a strong baseline. The app uses labels, tooltips, dialog primitives, and sr-only text in menu triggers. A few custom pieces would benefit from more attention, especially image fallbacks and drag-and-drop affordances.

What I would change next

If I were continuing this codebase, I would keep the general architecture but tighten the boundaries. First, I would stabilize the React Query provider and formalize query keys. Second, I would separate product and sale service contracts more aggressively so endpoint mix-ups become harder to write. Third, I would move at least part of auth enforcement into middleware or server-side route handling.

The larger lesson is that this app gets a lot of value from a modest amount of structure. Thin services, reusable query hooks, shared table infrastructure, and form-driven business rules go a long way in an internal dashboard. The tradeoff is that once those abstractions exist, they need naming discipline and a few guardrails. emoney-profit-tracker is a good example of a pragmatic frontend that solves a real operational problem while making its next engineering steps fairly obvious.

UICS Connect: A Technical Walkthrough of the Alumni Partnership System

Israel Michael — Thu, 09 Apr 2026 00:36:11 +0000

The alumni-partnership-system is a networking platform for the University of Ibadan Computer Science community. It connects students and alumni through profiles, posts, communities, jobs, direct messaging, notifications, and connection requests. It is a Next.js 14 App Router application that pushes a lot of behaviour to the client, uses Supabase as both database and auth boundary, and relies on React Query to keep the UI coherent while data changes quickly.

A school community needs more than a directory. It needs identity, lightweight publishing, private conversation, and a way to move between social and career features without building separate systems. UICS Connect treats the authenticated user as the centre of every workflow: sign in, hydrate user state, fetch domain data, then keep the UI current with optimistic updates and realtime subscriptions.

Architecture and Boundaries

The repository has a clean split between routing, domain logic, and UI composition. app/ owns layouts and pages. components/ contains shared UI, feature components, and provider setup. services/ is the domain layer for Supabase queries, mutations, file uploads, and permission checks. hooks/ wraps those services with React Query and turns them into UI-friendly primitives.

Authentication is handled in two places. middleware.ts delegates to lib/supabase/middleware.ts, which refreshes the session and redirects users based on route type. It also sanitizes the login callback so the app only redirects internally:

if (!user && !isPublicRoute) {
  const url = request.nextUrl.clone();
  url.pathname = "/login";
  if (pathname !== "/") {
    url.searchParams.set("callbackUrl", pathname);
  }
  return NextResponse.redirect(url);
}

That is paired with server-side auth actions in services/auth.service.ts, where login() calls redirect() only after checking callbackUrl.startsWith("/").

At the application shell level, components/providers/providers.tsx creates one QueryClient and wraps the tree with theme, push notification, keyboard command, and context providers. components/providers/context.tsx currently exposes an empty context object, which tells you what this codebase is not doing. Remote state lives in React Query. Local UI state stays local.

Data Flow and State Management

The dominant data flow looks like this: a component fires an event, a custom hook triggers a React Query mutation, the service module talks to Supabase, and the cache is updated optimistically or invalidated for refetch. If the feature needs live updates, a Supabase realtime channel patches the cache when rows change.

The post flow is the clearest example. app/(logged-in)/_components/post-composer.tsx collects content with TipTap, validates images, then calls useCreatePost(). That hook lives in hooks/use-posts.ts and delegates to createPost() in services/posts.service.ts. The same file also contains the more interesting mutations, especially optimistic updates for edits:

queryClient.setQueriesData({ queryKey: ["posts"] }, (old: any) => {
  if (!old?.pages) return old;

  return {
    ...old,
    pages: old.pages.map((page: any) => ({
      ...page,
      posts: page.posts.map((p: Post) =>
        p.id === postId ? { ...p, ...data, _optimistic: true } : p
      )
    }))
  };
});

That pattern shows up all over the app. hooks/use-chats.ts uses the same approach for messages, including temporary blob URLs for attachment previews and rollback on failure. The upside is responsiveness. The cost is cache bookkeeping when a mutation affects both an infinite list and a detail view.

Remote state is mostly React Query state. Local state is reserved for ephemeral interaction details. app/(logged-in)/chat/components/chat-zone.tsx keeps replyingTo, editingMessage, stickyDate, and scroll state in component memory because those values are view-specific and do not belong in shared cache.

Interesting Implementation Details

The feed and comment system carries some of the best engineering work in the repo. getPostComments() in services/posts.service.ts builds a nested tree in O(n) time using Map, then applies a ranking model that prioritizes the current user, then the post author, then engagement, then recency:

const commentMap = new Map<string, Comment>();
const repliesMap = new Map<string, Comment[]>();
const topLevelComments: Comment[] = [];

comments.forEach((comment) => {
  const commentWithLike: Comment = {
    ...comment,
    user_liked: likedCommentIds.has(comment.id),
    replies: []
  };
  commentMap.set(comment.id, commentWithLike);

That is a better choice than recursive insertion during fetch because it keeps the construction cost predictable as the thread grows. The companion realtime hook, usePostCommentsSubscription(), then merges inserts and deletes back into the cached tree instead of forcing a full reload.

Chat is the other area where the implementation gets interesting. services/chats.service.ts is more imperative than the post service because messaging needs attachment handling, unread counts, and reply references. useSendMessage() in hooks/use-chats.ts creates an optimistic message first, including local attachment previews, then replaces it when the insert completes. useChatSubscription() listens to postgres_changes for the current chat and merges new rows into ["chats", chatId, "messages"]. chat-zone.tsx then groups messages by day and collapses adjacent messages from the same sender in the same minute.

Communities and connections follow the same architectural style with less cache complexity. services/communities.service.ts handles membership joins, image uploads to the community-images storage bucket, search via textSearch("search_vector", filter.search), and role-aware membership state. services/connection.service.ts is careful about ownership, especially in acceptConnectionRequest(), rejectConnectionRequest(), and removeConnection().

API Integration, Performance, Security, and Accessibility

Most integration work happens from the browser through the Supabase client in services/*. That keeps feature code easy to follow, but it also means many services start with supabase.auth.getUser(). The repeated check adds chatter and keeps a lot of data access in the client. The main server-side exception is auth in services/auth.service.ts, plus app/api/link-preview/route.ts, which fetches arbitrary URLs and parses metadata with cheerio.

Performance-wise, the project makes several strong choices. The feed uses useInfiniteQuery() and useInView() for incremental loading in app/(logged-in)/_components/feed.tsx. Comments use linear-time tree construction. Posts, comments, and chat all use optimistic writes. Realtime subscriptions avoid waiting for manual refresh. next.config.mjs also enables PWA behavior through @ducanh2912/next-pwa.

There are tradeoffs. One global QueryClient in components/providers/providers.tsx is simple, but cache policy is mostly default behavior. Chat and community fetches still show some N+1 tendencies, particularly where last messages, participants, unread counts, and reply targets are fetched in follow-up queries. There is also no visible automated test suite, which makes optimistic and realtime paths riskier to change.

On security, the foundations are reasonable. Middleware protects private routes. Auth actions sanitize redirects. Service methods often check ownership before mutation. Still, the design assumes Supabase Row Level Security is doing a lot of the final enforcement. The link preview route deserves extra scrutiny because fetching arbitrary external URLs is exactly where SSRF concerns start.

Accessibility is mixed in the way many product-driven apps are mixed. The baseline is good because the app leans on Radix primitives like components/ui/dialog.tsx, which already carry focus management and semantics. Forms and buttons are generally explicit. But there is no dedicated accessibility layer or test strategy, so quality will depend on each custom component.

What I Would Keep and What I Would Change

The service-plus-hook split is the right core decision here. It keeps Supabase logic out of the view layer, makes React Query reusable, and gives the app room to add richer UX such as optimistic comments and live chat without turning components into query scripts.

What I would change is mostly about tightening boundaries. I would consolidate repeated auth and query helpers, move more high-value writes behind server-side boundaries, add tests around optimistic cache transitions, and review the N+1 paths in chat and community fetches. The current architecture works, but it is at the point where more features will increase coordination cost unless the data access patterns become more deliberate.

React vs Next.js vs TanStack Start: Deciding on the Right Tool

Israel Michael — Sun, 08 Feb 2026 16:32:51 +0000

React vs Next.js vs TanStack Start: Deciding on the Right Tool

Choosing the right tool for a frontend project is more than just picking something familiar. React, Next.js, and the new TanStack Start framework each solve similar problems in different ways, and understanding their design goals can help you make the best choice for your needs.

React: The Core UI Library

React is the foundational UI library for building interactive interfaces. It doesn’t come with routing, data fetching, or server rendering by default, but it gives you the pure building blocks — components, state, hooks, and rendering. React is flexible, battle-tested, and supported by a massive ecosystem of tools and libraries.

When to use React alone:

Your app is heavily interactive, and you don’t need server rendering.
You want total control over your stack and are comfortable choosing your own routing and data libraries.
You’re building dashboards, internal tools, or SPAs where SEO isn’t a priority.

React is essentially the baseline for everything that follows here.

Next.js: The Production Ready Framework

Next.js is built on top of React and adds routing, server rendering, static site generation, and automatic optimizations. It’s ideal for production applications where performance and SEO matter.

Next.js supports features like SSR, SSG, and incremental static regeneration out of the box, and its App Router makes server components the default. This can simplify building content-rich sites, but it also brings complexity and conventions you have to learn.

Strengths of Next.js:

Excellent SEO and performance with server rendering
Built-in file-based routing and tooling that gets you shipping quickly
Mature ecosystem and widespread adoption

Considerations:

Automatic caching and server component behavior can feel opaque to debug
It has heavier defaults and tight integration with the Vercel platform, though it can be deployed elsewhere

Next.js remains the established choice for content sites, e-commerce platforms, and applications where SEO or SSR is critical.

TanStack Start: A New Framework with Strong Dev Ergonomics

TanStack Start is a new full-stack React framework powered by TanStack Router and Vite. It aims to unify modern frontend needs with clearer control and a simpler mental model than larger frameworks, while still offering SSR, streaming, server functions, and deployment flexibility.

TanStack Start takes a different approach than Next.js. It uses traditional client-side React components that are server-rendered by default, giving you SSR benefits with full client-side interactivity. Server Components are planned but not yet supported.

TanStack Start is currently in release candidate and near v1, meaning it’s feature-complete and considered production-ready by many early adopters for real projects, even though it hasn’t reached a stable v1 release yet.

Strengths of TanStack Start:

Deep TypeScript support and type-safe routing
SSR and streaming through explicit primitives
Flexible deployment anywhere JavaScript runs
Developer experience powered by Vite with fast startup and HMR

Considerations:

Still newer than Next.js with a smaller ecosystem
Doesn’t support React Server Components yet, though integration is planned

Many developers report that Start feels closer to the React way of thinking, without as much framework magic, which leads to predictable behavior and easier debugging.

Which One Should You Choose?

React alone is a great core library for flexible UI work and complex SPAs.
Next.js shines when you need SEO, SSR, and a mature framework with established conventions.
TanStack Start is a promising alternative when you want performance, type safety, explicit control, and flexibility without the implicit complexity of larger frameworks.

These tools are not mutually exclusive. For example, you can use TanStack libraries like TanStack Query and Router within Next.js. Understanding the philosophy and current landscape helps you choose with confidence.

Mastering the art of frontend performance optimization

Israel Michael — Sun, 08 Feb 2026 15:48:56 +0000

As a Frontend Software Engineer, I’ve worked on a range of challenging projects, and one area I focus on constantly is frontend performance. Why? Because a fast, responsive application directly improves user experience, retention, and overall satisfaction.

Step 1: Don’t Ignore Performance Issues

It’s easy to overlook slow load times or laggy interfaces, but ignoring them is not just lazy programming—it can drive users away and hurt your product’s reputation. A smooth, efficient user experience is our responsibility as developers.

Why Performance Matters

User experience: Fast websites keep users happy; slow pages frustrate them.
SEO benefits: Search engines favor speed, boosting your site’s ranking.
Conversion rates: Quicker, responsive sites encourage users to stay and engage.

Effective Strategies I’ve Used

Refactoring: Optimizing and cleaning up code improves load times and maintainability.
Responsive design: Using React and Next.js, I ensure applications work seamlessly across desktops, tablets, and smartphones.
Advanced analytics: Tracking user interactions helps identify performance bottlenecks and improve UX based on real feedback.
Security measures: Secure APIs and strong authentication are essential for reliable, safe applications.

A Call to Action

Let’s take pride in our work and prioritize performance from the start. Fast, reliable applications are not just a technical goal—they shape the user’s experience and trust.

What are your go-to strategies for frontend performance optimization? Have you faced challenges in this area? Let’s share experiences and learn from each other.

Reach out if you’d like to discuss frontend development, ask questions, or collaborate on exciting projects. Stay curious and keep coding! 💻✨

The Principles of Good Design

Israel Michael — Sun, 08 Feb 2026 15:35:04 +0000

We’ve all experienced it—scrolling through social media and stopping at a design that just grabs your attention. It looks polished, engaging, and effortless. Then there are those designs that feel… off. They lack cohesion, confuse the viewer, or just don’t resonate.

Good design isn’t magic, but it can feel like it. A well-crafted graphic or interface can inform, entertain, and evoke emotion. The secret is understanding a few core principles that make design work.

Here are four key principles to level up your designs:

1. Contrast
Contrast adds visual interest by using opposing elements such as light and dark, big and small, or bold and subtle. Without it, a design feels flat and unengaging. Contrast helps guide the viewer’s eye through the composition.

2. Balance
Balance makes a design feel stable and harmonious. This doesn’t always mean symmetry. By distributing visual weight thoughtfully, you create a sense of order and cohesiveness that feels natural to the viewer.

3. Hierarchy
Not all information is equally important. Hierarchy uses size, colour, and placement to prioritize elements, guiding attention to the most crucial parts first. It ensures your message is clear and easily digestible.

4. Simplicity
Simplicity focuses on what matters most and removes distractions. A clean design communicates effectively and leaves a stronger impression. As Steve Jobs said, achieving simplicity requires effort, but the result allows your work to move mountains.

Mastering these principles allows you to create designs that captivate, inform, and leave a lasting impression.

Syncing Data Across Browser Tabs in Next.js: A Frontend 'Cron Job' Solution for Timed Fetching

Israel Michael — Sun, 08 Feb 2026 15:26:54 +0000

Imagine this. You are building a dynamic Next.js app where data needs to refresh every two minutes. Sounds simple. Drop a setInterval inside useEffect and move on.

That was my assumption too, until I opened multiple browser tabs.

Each tab was fetching data on its own schedule. Nothing was aligned. One tab refreshed, another lagged behind, and the experience felt messy. That was not acceptable.

This post documents how I solved that problem by building a frontend “cron job” that synchronizes data fetching across all open tabs. I will walk through the initial approach, the issue it caused, and the solution that finally made everything click.

Starting out: the timer-based approach

I began with a straightforward setup. Fetch on mount, then fetch every two minutes.

"use client";

import { useEffect, useState } from "react";

export default function Page() {
  const [data, setData] = useState(null);

  const fetchData = async () => {
    const response = await fetch("/api/getData");
    const newData = await response.json();
    setData(newData);
  };

  useEffect(() => {
    fetchData();
    const interval = setInterval(fetchData, 120000);
    return () => clearInterval(interval);
  }, []);

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

At first glance, this works perfectly.

The problem: tabs falling out of sync

The issue appeared as soon as I opened a second tab.

Each tab runs its own instance of setInterval, which means timing depends on when the tab was opened.

For example:

Open tab A at 12:01. It fetches at 12:03, 12:05, and so on.
Open tab B at 12:02. It fetches at 12:04, 12:06, and so on.

Same app, same user, different data states. That inconsistency was the real problem.

What I actually needed was this:

All tabs should fetch at the same exact moments. Ideally at fixed two minute boundaries like 12:00, 12:02, 12:04, no matter when the tab was opened.

The idea: align all fetches to real time

Instead of starting a timer immediately, I decided to align fetching to the clock.

The plan was simple:

Calculate how long until the next even two minute mark.
Wait until that moment using setTimeout.
From there, run a steady two minute interval using setInterval.

This way, every tab locks onto the same schedule.

The final implementation

"use client";

import { useEffect, useState, useCallback } from "react";

export default function Page() {
  const [data, setData] = useState(null);

  // Fetch function wrapped in useCallback to prevent unnecessary re-renders
  const fetchData = useCallback(async () => {
    try {
      const response = await fetch("/api/getData");
      const newData = await response.json();
      setData(newData);
    } catch (err) {
      console.error("Error fetching data:", err);
    }
  }, []);

  useEffect(() => {
    // Fetch immediately on mount so users don't wait up to 2 minutes
    fetchData();

    // Get current time
    const now = new Date();

    // Calculate milliseconds until the next even 2-minute mark (12:00, 12:02, 12:04, etc.)
    // Formula: 120000ms (2 min) - (current position within 2-min cycle)
    const millisecondsUntilNextEvenMinute =
      120000 - 
      ((now.getMinutes() % 2) * 60000 +  // Minutes component
       now.getSeconds() * 1000 +          // Seconds component
       now.getMilliseconds());            // Milliseconds component for precision

    // Variable to store the interval ID so we can clear it on cleanup
    let intervalId;

    // Wait until the next even 2-minute boundary
    const timeoutId = setTimeout(() => {
      // Fetch at the exact 2-minute mark
      fetchData();

      // Now that we're synced, fetch every 2 minutes going forward
      intervalId = setInterval(fetchData, 120000);
    }, millisecondsUntilNextEvenMinute);

    // Cleanup function: clear both timeout and interval to prevent memory leaks
    return () => {
      clearTimeout(timeoutId);
      if (intervalId) clearInterval(intervalId);
    };
  }, [fetchData]); // Include fetchData in dependencies

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

What is happening here

Initial delay calculation
I calculate how many milliseconds remain until the next even two minute mark.
Delayed first fetch
setTimeout ensures the first fetch happens exactly on that boundary.
Stable interval after sync
Once aligned, setInterval keeps all tabs fetching together every two minutes.

The result

Now every tab behaves the same way:

Open a tab at 12:01:29. It waits until 12:02:00, then fetches every two minutes.
Open another tab at 12:01:58. It waits two seconds, then fetches at 12:02:00 alongside the first tab.

Perfect sync, every time.

Final thoughts

This change looks small, but it dramatically improved consistency across tabs. The pattern behaves like a frontend cron job, anchored to real time rather than tab lifecycle.

When this approach makes sense

This is useful when:

Data needs to stay consistent across multiple open tabs.
Timing matters more than “fetch every X minutes from mount”.
A plain setInterval introduces drift you cannot afford.

Sometimes the difference between working code and reliable code is simply aligning with time instead of starting from zero.

Is "use client" Bad for SEO?

Israel Michael — Sun, 08 Feb 2026 15:18:35 +0000

If you've been working with Next.js lately, you've probably seen the use client directive pop up in components. It's just one line at the top of a file, but it raises an important question: does it affect SEO?

Short answer: No. Client components don't hurt SEO. Let me explain why.

What use client actually does

In Next.js 13 and above, components are server components by default. When you add use client to a component, you're telling Next.js this component needs client-side features like:

State (useState, useEffect)
Event handlers
Browser-only APIs (like window or localStorage)
Animations or heavy interactivity

Here's the key thing: Client components are still pre-rendered on the server and included in the initial HTML. Search engines see them immediately, exactly the same as server components.

The difference is that client components are also bundled and sent to the browser for hydration—making them interactive.

Why people think use client hurts SEO (and why they're wrong)

There's a common misconception that client components aren't server-rendered. This isn't true.

Both server components and client components appear in the initial HTML that gets sent to the browser. From a crawler's perspective, there's no difference. Google sees the content immediately either way.

So putting an <h1>, product description, or blog content in a client component is totally fine for SEO. The content is there in the HTML from the start.

What actually matters for SEO

While use client itself doesn't hurt SEO, there are two things that DO matter:

1. Don't hide content behind interactivity

This is the real SEO risk. If content only appears after a user clicks a button, opens a tab, or submits a form, crawlers won't see it.

Crawlers load the page and run JavaScript, but they don't interact with it. They don't click buttons or switch tabs.

Bad for SEO:

Product details hidden behind a "Read More" button
Pricing shown only after selecting a tab
Content that requires form submission to view

Fine for SEO:

Interactive components that render content immediately
Client components with state that shows content on load
Animations that don't hide initial content

2. Be mindful of performance

Client components increase your JavaScript bundle size. If you're overusing use client across your entire app, you can end up with a bloated bundle that slows down your site.

Performance affects SEO indirectly through Core Web Vitals and page speed rankings. But this is a holistic concern about your app's architecture, not a per-component decision.

You shouldn't avoid putting an <h1> in a client component just because it's an <h1>. If that component needs interactivity, use use client. The performance cost comes from the component being in the bundle, not from what content it contains.

The actual decision tree

When deciding between server and client components, ask yourself:

Does this component need client-side features?

State management?
Event handlers?
Browser APIs?
Interactivity after page load?

Yes? → Use use client

No? → Keep it as a server component

That's it. It's about functionality, not SEO.

How to use use client correctly

DO use use client for:

Forms with validation
Interactive widgets
Modals and dialogs
Tabs (as long as content is visible on initial render)
Animations
Any component that needs state or browser APIs

DON'T worry about:

Whether the component contains an <h1> or important text
Search engine indexing—crawlers see client components just fine
Per-component performance decisions based on content type

DO worry about:

Hiding content behind clicks, tabs, or interactions
Overall bundle size if you're using use client everywhere
Whether you actually need client features or just defaulted to use client out of habit

The bottom line

use client doesn't hurt SEO. Both client and server components appear in the initial HTML that crawlers see.

The choice between them should be based on whether you need client-side features, not whether the content is important for SEO.

The real SEO concerns are:

Hiding content behind interactivity that requires user action
Overall app performance from excessive JavaScript bundles

Get those right, and you can use client components wherever you need them without worrying about SEO.

Note: An earlier version of this post incorrectly stated that client components aren't server-rendered and recommended against putting SEO-important content in them. That was wrong. Thanks to the Vercel and Next.js team for the corrections.

Stop Using Redux for Request-Response Management – It’s Making Your Life Harder

Israel Michael — Sun, 08 Feb 2026 15:11:35 +0000

Let me be blunt: if you’re still using Redux to manage API requests, you’re making your life harder than it needs to be.

Redux has had a legendary run. For years, it was the default state management choice for React apps. Many of us learned it early, shipped production apps with it, and defended it in code reviews. But here’s the part that often gets ignored: Redux was never designed to manage server state.

Yet somehow, it became the go-to tool for handling API requests, responses, loading states, caching, retries, and everything in between. And if you’ve ever felt like that setup is exhausting, frustrating, or unnecessarily complex, you’re not imagining things. It really is that bad.

The good news is that it doesn’t have to be this way. There’s a tool that actually understands server state, and that tool is React Query.

Why Redux Falls Apart With API Calls

Using Redux for request-response data feels a bit like forcing a tool to do a job it was never built for. Yes, it can work, but the friction is constant.

First, there’s the boilerplate. For a single API call, you define request, success, and failure action types. Then you write action creators. Then reducers. Then middleware like thunk or saga just to make async logic possible. After all that, you still have to manually track loading states, error states, caching behavior, and refetch logic in your UI.

All of this effort just to fetch data and display it.

Second, Redux has no concept of stale data. Server data changes over time, but Redux doesn’t know that. If you want fresh data, you have to explicitly tell it when to refetch. That means more logic for pagination, refetch-on-focus, refetch-on-mount, background updates, and avoiding duplicate requests. Miss one edge case, and suddenly your users are looking at outdated data.

Then there’s the bigger design issue: not all API data belongs in global state. Many API responses are temporary, screen-specific, or tied to a single user flow. Redux forces everything into a global store, which makes debugging harder and bloats your state with data that doesn’t need to live there long-term.

At some point, you step back and realize you’re fighting the tool instead of using it.

Where React Query Changes Everything

React Query flips the entire approach. Instead of treating server data like client state, it treats it as what it really is: data that comes from the server and needs to stay in sync with it.

There’s no boilerplate circus. You write a query, get your data, loading state, and errors from a hook, and move on. No actions. No reducers. No middleware. Just data.

Caching is automatic. React Query knows when data is fresh, when it’s stale, and when it should refetch. It updates data when users revisit a page, when the browser regains focus, or when a mutation changes something on the server. You don’t write extra logic for this. It just happens.

Mutations are where the difference really shows. Things like optimistic updates, retries, and error handling that are painful in Redux become straightforward. You describe what should happen, and React Query handles the mechanics.

The result is code that’s easier to read, easier to reason about, and far less fragile.

Does This Mean Redux Is Dead?

Not at all. Redux is still useful for client state. UI state, authentication state, feature flags, theme settings, and other global concerns still fit nicely there.

But server state is a different problem space. Treating it like client state is the mistake. Once you separate the two, things click into place very quickly.

The Takeaway

If you’re using Redux for API requests because “that’s how it’s always been done,” it might be time to reassess. There’s no prize for maintaining 500 lines of boilerplate just to fetch data.

React Query exists because this problem needed a better solution. Less code. Fewer bugs. Better performance. Saner defaults.

Your future self will appreciate the switch.