DEV Community: Francisco Moretti

Fix mobile keyboard overlap with VisualViewport

Francisco Moretti — Mon, 25 Aug 2025 10:08:58 +0000

Fix mobile keyboard overlap with dvh (no observers)

Edited 2025-08-26: The previous version recommended syncing visualViewport.height to a CSS variable with an observer. That was wrong for this use case. The actual fix in Sparka is to rely on dynamic viewport units (dvh). Drop the observer and use Tailwind’s h-dvh. See the discussion: https://github.com/FranciscoMoretti/sparka/issues/14

Introduction

Bottom‑pinned chat inputs can get buried when the mobile keyboard opens. Modern browsers expose dynamic viewport units that account for the on‑screen keyboard. Use dvh and keep the layout simple.

This is used in Sparka.ai, you can check the code here.

The fix

Use h-dvh (Tailwind) for any full‑height containers.
No observers, no CSS variables, no JS.

// components/chat.tsx (snippet)
<div className="flex h-dvh min-w-0 flex-col">{/* content */}</div>

If you need a single element to fill the screen:

<div className="h-dvh" />

Notes

dvh reflects the visible viewport height, adjusting when the keyboard shows.
Works on iOS Safari and Android (recent versions). If you must support very old iOS, feature‑test and fall back to 100vh.

Viewport meta

If you also want Android/Chromium to resize content with the keyboard, set interactiveWidget: 'resizes-content'. This is additive to using dvh.

// app/layout.tsx (snippet)
export const viewport = {
  maximumScale: 1, // Disable auto-zoom on mobile Safari
  interactiveWidget: 'resizes-content' as const,
}

Details: https://developer.chrome.com/docs/web-platform/viewport-meta/#interactive-widget

In the wild

This is what Sparka.ai ships. For context, see the issue: https://github.com/FranciscoMoretti/sparka/issues/14

Deep Research UIs - Perplexity vs. Manus vs. ChatGPT vs. Gemini

Francisco Moretti — Tue, 29 Apr 2025 18:37:53 +0000

Building chat applications often involves tackling complex user interfaces. This is especially true for "deep research" tasks where information density is high. Components like reports, research steps, sources, and source citations create unique UI challenges. This post looks at how four AI chat tools (Perplexity, Manus, ChatGPT, and Gemini) approach these challenges. By checking out their UI decisions and trade-offs, particularly using Vercel's AI SDK message schema, we can find valuable lessons for designing effective research-focused chat interfaces.

Vercel AI SDK UI message schema

The Vercel AI SDK provides a structured approach for building chat interfaces through its message schema. Understanding this schema helps us analyze how different research tools implement their interfaces.

A simplified version of the Vercel AI SDK UI message schema includes:

UiMessage: A message in the chat. It represents the entire message unit from either a user or the AI assistant.
Annotation: Information tied to a message that can be streamed before the response is written. These are useful for showing intermediate research steps, thinking processes, or source gathering.
UiMessagePart: A piece of a message like text, code, or an image. Complex research responses often combine multiple part types to create rich information displays.

// Simplified relationship between UiMessage, Annotation, and UiMessagePart

// UiMessagePart represents different parts of the message content
type TextUIPart = {
  type: 'text'
  text: string
}

type ToolInvocationUIPart = {
  type: 'tool-invocation'
  toolInvocation: ToolInvocation // Tool invocation is a discriminated union of tool info (results and calls)
}

// UiMessage represents a complete message unit in the chat
type UiMessage = {
  id: string
  role: 'user' | 'assistant'
  createdAt: Date
  parts: Array<
    | TextUIPart
    | ReasoningUIPart
    | ToolInvocationUIPart
    | SourceUIPart
    | FileUIPart
    | StepStartUIPart
  > // A message consists of multiple parts. A discriminated union of parts types
  annotations?: JSONValue[] // A discriminated union of annotation types
}

When implementing a research interface, developers can use these components to create different arrangements of information. Each research tool we look at makes different choices about how to structure and present information using similar underlying components.

The complexity comes from balancing information density with usability. Research interfaces must present substantial information without overwhelming users. How each tool handles this balance is a core part of our analysis.

Perplexity UI breakdown

Perplexity uses a simple approach for research presentation. Their interface emphasizes readability while keeping the contextual richness needed for deep research tasks.

The main answer or "report" appears as a standard message in the chat. It has no special formatting to distinguish it from other messages. This simplifies the UI but might make it harder for users to spot the final answer among regular conversation messages.

What stands out most about Perplexity is its treatment of sources. Sources appear in many places:

Inline citations within the text (numbered references)
A dedicated sources panel at the top of each research response + available as a "Sources" tab

This dual approach gives sources high visual prominence while maintaining the flow of the main content. Implementing this in the Vercel AI SDK schema might use:

A primary UiMessagePart for the text content
Annotation components to hold the source references
Custom styling to visually link inline citations with their corresponding entries

Key benefits:

Builds user trust through clear attribution
Makes fact-checking easy with prominent sources
Keeps content flow clean with numbered references

Drawbacks:

Interface can become cluttered with many sources

Perplexity also includes suggested follow-up questions at the end of responses. They serve as navigation aids and subtle guides toward productive use of the tool.

Manus UI breakdown

Manus takes a different approach to research interfaces. It makes the research process itself a central part of the user experience. Their interface splits attention between the research output and the research method.

"Research Steps" occupy a significant portion of the screen real estate. This makes the process transparent to users. Unlike interfaces focusing solely on the result, Manus treats the journey as equally important.

One notable feature is how Manus handles planning. The interface displays an explicit research plan but doesn't pause for user confirmation or feedback. It does ask clarifying questions when needed, though. This can create a smoother experience when it gets things right, but it depends heavily on the quality of the decision making.

Manus generates multiple documents during research, providing info about intermediate steps. While informative, this approach can reduce the visual importance of the primary document requested by the user. The final output becomes just one of several documents, not the clear focal point.

The 2-panel layout with a "computer view" on the right aims to show how the agent works in real time. This provides transparency but uses significant screen space. Its value diminishes during routine web browsing, which makes up most of the research process.

Using the Vercel AI SDK schema, this approach might be implemented with:

Multiple UiMessage components for different document types
Annotation objects to represent each research step
A mechanism for Annotation objects representing tool calls to fetch and show the correct 'computer view' content for that step

Key benefits:

Process transparency builds user trust
Research journey visibility helps understanding
Real-time insights into AI thinking

Drawbacks:

Interface feels busier and potentially overwhelming
Requires complex state management

ChatGPT UI breakdown

ChatGPT takes a more balanced approach to research interfaces. It focuses on user control while keeping a clean presentation. It starts with a plan as a TextUIPart that needs feedback via a normal conversation message. This offers familiarity, practicality, and flexibility.

Before conducting research, ChatGPT typically presents a research plan as a regular text message part and asks for user feedback. This creates a pause point that gives users agency in the research process. They can approve, modify, or redirect the plan before execution starts.

For research steps, ChatGPT initially displays them in an expandable sheet that updates in real time. This keeps the research process visible without dominating the interface. Once research finishes, these steps collapse into a compact component within the conversation. This creates a clean history that can be referenced if needed.

The final report appears as a ToolInvocation piece of the regular answer, styled like a card. This works well for shorter reports but can become cluttered for longer, more complex responses. The lack of dedicated document viewing capabilities limits the reading experience for extended content.

Using the Vercel AI SDK schema, this approach might be implemented with:

A normal text UiMessagePart for the initial plan
Annotation objects for the research steps that can toggle between expanded and collapsed states
A ToolInvocation part for the final report content

Key benefits:

User control through plan feedback
Clean interface maintains familiarity
Collapsible research steps reduce clutter

Drawbacks:

Limited support for longer reports
Reading experience suffers in standard chat format

Gemini UI breakdown

Gemini offers a distinct approach to research interfaces. It has a strong focus on the final output while still providing process transparency. The interface uses a two-panel design that separates the conversation from research details.

The planning approach in Gemini appears as a special UI element (a tool result), though the core content is primarily text with minimal formatting. Plan acceptance is handled through a button that creates a standard message response, rather than specialized UI controls.

Research progress updates appear in the secondary panel labeled "Thoughts". This provides insight into the ongoing process and creates clear separation between the conversation and the research mechanics.

When research completes, Gemini displays the document (report) in the secondary panel. Research steps are positioned below the report content. This creates a hierarchy that emphasizes results over process. However, this arrangement requires significant scrolling to review the research steps, making them less accessible than in other interfaces.

Sources receive some visual emphasis in the Gemini UI but remain integrated within the report. This approach creates a cleaner appearance but may reduce source prominence compared to interfaces like Perplexity that highlight attribution more explicitly.

Using the Vercel AI SDK schema, this approach might be implemented with:

A ToolInvocation for the initial plan
Annotation objects for the "Thoughts" that update during research
Another ToolInvocation for the final report
A separate UI component outside the main message thread for displaying both the report and research steps

Key benefits:

Clear focus on final output
Clean conversation, separate from research details
Good separation of conversation and supporting information

Drawbacks:

Reduced visibility of research steps after completion
Sources less prominent than other approaches
Requires managing a more complex layout

Conclusion

Comparing these four tools reveals a spectrum of UI strategies for deep research. Perplexity prioritizes source prominence and readability, Manus emphasizes process transparency, ChatGPT balances user control with a clean interface, and Gemini focuses strongly on the final report within a separated layout. Each approach involves trade-offs between information density, process visibility, user control, and interface complexity. Understanding these design choices and their implications offers valuable insights for developers building AI-powered research tools.

What tests to write for React

Francisco Moretti — Fri, 04 Apr 2025 19:06:11 +0000

This article explores what tests you should be writing for your web applications. Inspired by Igor Luchenkov's insightful talk at React Advanced London and drawing on wisdom from industry experts, we'll look at how testing strategies have evolved from the classic Test Pyramid to the more nuanced Testing Trophy approach.

The evolution of testing strategies

For years, the dominant testing strategy in software development was Martin Fowler's Test Pyramid. This model suggested having many unit tests at the bottom, fewer integration tests in the middle, and even fewer end-to-end tests at the top.

The pyramid made sense when it was created. Back then, running tests through a UI was painfully slow, expensive to set up, and notoriously brittle. A small change in the UI could break dozens of tests, requiring hours of maintenance.

But times have changed. Modern testing tools have evolved dramatically, making some of the pyramid's assumptions outdated. This led Kent C. Dodds to propose an updated model - the Testing Trophy.

Inspired by Guillermo Rauch's tweet:

"Write tests. Not too many. Mostly integration."

The trophy flips the script by placing integration tests as the largest, most important section. It also adds a new foundation: static tests. This shift reflects how testing tools and web development have evolved in recent years.

Understanding the Testing Trophy

The Testing Trophy consists of four distinct layers:

The types of tests are:

End-to-End (Full app)
Integration (Component interactions)
Unit (Logic in isolation)
Static (Typing, linting, etc.)

Static (The Base)

These aren't traditional tests that run your code. Instead, they check your code without executing it. TypeScript, ESLint, and Biome fall into this category. They catch typos, type errors, and enforce coding standards with minimal effort.

Unit (The Small Base)

Unit tests verify that individual functions work correctly in isolation. They're fast and focused but don't tell you if your components work well together.

Integration (The Trophy Cup)

This is the largest section of the trophy for good reason. Integration tests verify that multiple units work together correctly. In web development, this often means testing how components interact without mocking every dependency.

End-to-End (The Top)

These comprehensive tests simulate real user behavior, often through a browser. They're the most confidence-inspiring but also the slowest and most complex to maintain.

Why integration tests deserve the spotlight

In 2016, Guillermo Rauch (creator of Socket.io and founder of Vercel) tweeted a simple yet profound message:

"Write tests. Not too many. Mostly integration."

This wasn't just a catchy phrase - it's solid advice backed by practical experience. Integration tests strike the perfect balance between confidence and cost.

Unit tests are quick to write and run, but they don't tell you if your components actually work together. End-to-end tests give you the most confidence but are slow and high-maintenance. Integration tests hit the sweet spot:

They provide high confidence that your features work
They run reasonably fast
They're more resilient to refactoring than unit tests
They catch real issues that users might encounter

Kent C. Dodds put it brilliantly when he said: "The more your tests resemble the way your software is used, the more confidence they can give you."

Integration tests mirror how users actually experience your software better than isolated unit tests, making them more valuable for the time invested.

Small examples of each test type

Static Tests

// TypeScript will catch this error without running any code
function addNumbers(a: number, b: number): number {
  return a + b
}

addNumbers('5', 10) // Error: Argument of type 'string' is not assignable to parameter of type 'number'

ESLint rules can catch potential bugs:

// ESLint no-unused-vars rule
function calculateTotal(subtotal, tax) {
  const total = subtotal + tax
  // Error: 'total' is assigned a value but never used
}

Unit Tests

Using Vitest to test a simple utility function:

// utils.js
export function formatPrice(amount) {
  return `$${amount.toFixed(2)}`
}

// utils.test.js
import { test, expect } from 'vitest'
import { formatPrice } from './utils'

test('formats the price with dollar sign and two decimal places', () => {
  expect(formatPrice(10)).toBe('$10.00')
  expect(formatPrice(10.5)).toBe('$10.50')
})

Integration Tests

Testing a form component with React Testing Library:

// LoginForm.test.jsx
import { render, screen, fireEvent } from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import LoginForm from './LoginForm'

test('submits the form with user credentials', async () => {
  const handleSubmit = vi.fn()
  render(<LoginForm onSubmit={handleSubmit} />)

  await userEvent.type(screen.getByLabelText(/email/i), 'user@example.com')
  await userEvent.type(screen.getByLabelText(/password/i), 'password123')
  await userEvent.click(screen.getByRole('button', { name: /log in/i }))

  expect(handleSubmit).toHaveBeenCalledWith({
    email: 'user@example.com',
    password: 'password123',
  })
})

End-to-End Tests

Using Playwright to test the login flow:

// login.spec.js
import { test, expect } from '@playwright/test'

test('user can log in', async ({ page }) => {
  await page.goto('/login')

  await page.fill('input[name="email"]', 'user@example.com')
  await page.fill('input[name="password"]', 'password123')
  await page.click('button[type="submit"]')

  // Verify user was redirected to dashboard
  await expect(page).toURL('/dashboard')
  await expect(page.locator('h1')).toContainText('Welcome back')
})

Recommended Frameworks for each test type

Static Testing

TypeScript: Adds type-checking to JavaScript
ESLint: Identifies problematic patterns
Biome: Modern linter and formatter

Unit Testing

Vitest: Fast unit test runner with great React support

Integration Testing

Vitest: Fast unit test runner with great React support
Storybook: Component workshop for visual testing and development

End-to-End Testing

Playwright: Modern E2E testing tool with cross-browser support

Balancing your test portfolio for maximum value

While the Testing Trophy offers a good template, your ideal test mix depends on your project. Consider these factors when deciding:

Application complexity: More complex apps need more integration and E2E tests
Team size: Larger teams benefit from more tests as communication overhead increases
Stability requirements: Critical systems need more test coverage
Development phase: Early-stage products might focus on fewer, high-value tests

Remember these practical tips:

Start with static type checking and linting - they're the cheapest way to catch errors
Don't aim for 100% test coverage; it often leads to testing implementation details
Focus on user workflows rather than implementation details
If a test is hard to write, it might be telling you something about your code design

By following the Testing Trophy approach and adjusting for your specific needs, you'll build a test suite that gives you confidence without slowing down development.

Next.js Authentication Best Practices in 2025

Francisco Moretti — Tue, 01 Apr 2025 08:52:16 +0000

Note: This article updates previous authentication guide, which contained outdated recommendations. Next.js has since changed its authentication guidance, particularly in light of the CVE-2025-29927 security vulnerability.

This articles containes a simplified version of the official Next.js authentication guide.

Why Next.js Authentication Guidance Has Changed

The Next.js team has significantly updated their authentication recommendations. The most important change: middleware is no longer considered safe for authentication. Instead, the new approach focuses on:

Using Data Access Layers (DAL)
Centralizing authentication logic
Keeping auth checks close to data access
Implementing proper role-based access in Server Components

Let's explore these updated best practices in detail.

Data Access Layers: The New Best Practice

A Data Access Layer centralizes all data access logic, including authentication checks. This approach provides:

Consistent security across your application
Protection against unauthorized data access
Clear separation between authorization and data fetching

Here's a simple example of a DAL implementation:

// app/lib/dal.ts
import { cache } from 'react'
import { cookies } from 'next/headers'
import { redirect } from 'next/navigation'

export const verifySession = cache(async () => {
  const cookieStore = cookies()
  const sessionToken = cookieStore.get('session-token')?.value

  if (!sessionToken) {
    return null
  }

  try {
    // Verify token with your auth provider
    const session = await validateToken(sessionToken)
    return session
  } catch (error) {
    console.error('Invalid session')
    return null
  }
})

export const getUser = cache(async () => {
  const session = await verifySession()

  if (!session) {
    return null
  }

  try {
    // Get user data using the session
    const data = await db.query.users.findMany({
      where: eq(users.id, session.userId),
      columns: {
        id: true,
        name: true,
        email: true,
      },
    })

    return data[0]
  } catch (error) {
    console.error('Failed to fetch user')
    return null
  }
})

The Problem with Middleware for Authentication

Middleware in Next.js executes before the application renders. While this appears ideal for authentication, there are significant limitations:

Static Routes Vulnerability: Middleware doesn't completely protect statically generated routes, as the content is already built
Limited Context: Middleware has limited access to the application's full context
Complexities with Static Generation: Auth logic in middleware can conflict with Next.js's static optimization

Proximity Principle: Auth Checks Close to Data

The proximity principle is now more important than ever. Keep authentication checks as close as possible to where sensitive data is accessed:

// Direct data access with auth check
async function fetchSensitiveUserData(userId: string) {
  const session = await verifySession()

  if (!session || session.user.id !== userId) {
    throw new Error('Unauthorized')
  }

  // Fetch and return data only after verifying
  return await db.users.findUnique({ where: { id: userId } })
}

Server Components and Role-Based Authentication

Server Components provide a powerful way to implement role-based access control:

// app/admin/page.tsx
import { verifySession } from '@/app/lib/dal'
import { redirect } from 'next/navigation'

export default async function AdminDashboard() {
  const session = await verifySession()

  if (!session) {
    redirect('/login')
  }

  if (session.user.role !== 'admin') {
    // User is logged in but not an admin
    redirect('/dashboard')
  }

  return (
    <div>
      <h1>Admin Dashboard</h1>
      {/* Admin-only content */}
    </div>
  )
}

Authentication in Layouts: Proceed with Caution

Due to partial rendering in Next.js, authentication in layouts requires special care:

Layouts don't re-render on navigation within their subtree
Auth checks may not run on every route change

Instead of relying on layout-level checks, perform authentication checks:

In your Data Access Layer
In page components
Directly in data fetching functions

Securing Data Access and Mutations

Server Actions and data transfer operations need special protection as they're entry points to your application's data. Implement these practices for robust security:

Always authenticate in Server Actions: Server Actions can be called directly from clients, so validate sessions before performing operations
Use DTOs to control data exposure: Never return complete data objects to clients - expose only what's necessary
Add role-based permissions: Check not just authentication but authorization for specific operations

Here's how to secure a Server Action:

// app/lib/actions.ts
'use server'

import { verifySession } from '@/app/lib/dal'

export async function updateUserProfile(formData: FormData) {
  // Auth check before any operation
  const session = await verifySession()
  if (!session) throw new Error('Unauthorized')

  // Get only the fields you need
  const userId = session.user.id
  const name = formData.get('name')

  // Validate input data
  if (!name || typeof name !== 'string') {
    throw new Error('Invalid input')
  }

  // Update only for authorized users
  return await db.users.update({
    where: { id: userId },
    data: { name },
  })
}

For data retrieval, use DTOs to limit exposure of sensitive data:

// app/lib/dto.ts
import 'server-only'
import { getUser } from '@/app/lib/dal'

export async function getUserProfileDTO(userId: string) {
  // Authentication check
  const currentUser = await getUser()
  if (!currentUser) return null

  // Authorization check
  const isAdmin = currentUser.role === 'admin'
  const isSelf = currentUser.id === userId
  if (!isAdmin && !isSelf) return null

  // Get the user data
  const userProfile = await db.users.findUnique({
    where: { id: userId },
    select: { id: true, name: true, email: true, role: true },
  })

  // Return only appropriate fields
  return {
    id: userProfile.id,
    name: userProfile.name,
    email: isAdmin || isSelf ? userProfile.email : null,
    role: isAdmin ? userProfile.role : null,
  }
}

By consistently implementing these patterns at every data entry and exit point, you maintain a secure boundary around your application's data.

Context Providers: Client-Side Limitations

React Context providers work for auth state due to Next.js's component interleaving architecture. However, there's an important limitation: React Context is not supported in Server Components and only works with Client Components.

When using a Context provider for authentication:

// app/providers.tsx
'use client'

import { createContext, useContext, useState, useEffect } from 'react'

const AuthContext = createContext(null)

export function AuthProvider({ children }) {
  const [user, setUser] = useState(null)
  const [loading, setLoading] = useState(true)

  useEffect(() => {
    // Fetch user on client
    async function loadUserFromAPI() {
      try {
        const res = await fetch('/api/user')
        const userData = await res.json()
        setUser(userData)
      } catch (error) {
        setUser(null)
      } finally {
        setLoading(false)
      }
    }

    loadUserFromAPI()
  }, [])

  return <AuthContext.Provider value={{ user, loading }}>{children}</AuthContext.Provider>
}

export const useAuth = () => useContext(AuthContext)

This approach works with Client Components that need authentication state:

// app/components/profile.tsx
'use client'

import { useAuth } from '../providers'

export function Profile() {
  const { user, loading } = useAuth()

  if (loading) return <div>Loading...</div>
  if (!user) return <div>Please log in</div>

  return <div>Welcome, {user.name}!</div>
}

However, any Server Components inside your component tree will be rendered on the server first, before the client-side context is available. This means:

Server Components cannot access context values
They cannot conditionally render based on authentication state from context
You'll need to use your DAL for any auth checks in Server Components

This is why a dual approach is recommended:

Use DAL for Server Components and data access
Use Context for Client Components that need real-time auth state

Note that sharing sensitive session information between server and client components requires careful handling to prevent security issues.

Security Best Practices Summary

Protect your Next.js app at multiple layers for maximum security:

Data layer: Add auth checks directly in your Data Access Layer functions
Route level: Check authentication in page components
UI elements: Hide sensitive components when users aren't authenticated
Server actions: Verify authentication in all mutation functions

For best results:

Replace middleware with a Data Access Layer for auth checks
Put auth checks as close as possible to where data is accessed
Be careful with layout-level authentication
Add proper auth verification in Server Components and Actions
Use Data Transfer Objects to control exactly what data gets exposed

This multi-layered approach creates apps that stay secure and easy to maintain without adding unnecessary complexity.

References

Authentication - Next.js Official Documentation

Automate Your Job Search: Scraping 400+ LinkedIn Jobs with Python

Francisco Moretti — Mon, 20 Jan 2025 19:49:22 +0000

The average job seeker spends 11 hours per week searching for jobs, according to LinkedIn. For tech roles, it's even worse, you're dealing with hundreds of postings across multiple platforms. When my partner started her job search, she was spending hours daily just scrolling through LinkedIn. There had to be a better way.

The Challenge

For Web developers, the market is overwhelming. A single search for "Frontend Developer" in London returned 401 results. Each posting requires:

5 seconds to review the title
3-4 clicks to view details
30-60 seconds to scan requirements
Manual copy-pasting to track interesting roles
Constant tab switching and back-navigation

For 401 jobs, that's hours of pure mechanical work!

The Solution: Automation Pipeline

I built a three-step automation pipeline that cut the process down to 10 minutes:

Scrape job data using Python
Filter in bulk using Google Sheets
Review only the most promising matches

Step 1: Smart Scraping

I used JobSpy as the base and built JobsParser to handle:

CLI
Rate limiting (to avoid LinkedIn blocks)
Retry logic for failed requests

Here's how to run it:

pip install jobsparser

Bonus: search manually on LinkedIn the number of results for your search term and use it for the --results-wanted parameter.

jobsparser \
    --search-term "Frontend Developer" \
    --location "London" \
    --site linkedin \
    --results-wanted 200 \
    --distance 25 \
    --job-type fulltime

If jobsparser is not in your path, you can run it as a module directly:

python -m jobsparser \
    --search-term "Frontend Developer" \
    --location "London" \
    --site linkedin \
    --results-wanted 200 \
    --distance 25 \
    --job-type fulltime

The output is a CSV with rich data:

Job title and company
Full description
Job type and level
Posted date
Direct application URL

JobSpy and JobsParser are also compatible with other job boards like LinkedIn, Indeed, Glassdoor, Google & ZipRecruiter.

Step 2: Bulk Filtering

While pandas seemed obvious (and I've given it a fair try), Google Sheets proved more flexible. Here's my filtering strategy:

Time Filter: Last 7 days

Jobs older than a week have lower response rates
Fresh postings mean active hiring

Experience Filter: "job_level" matching your experience:

For my partner who is looking for her first role, I filtered:

"Internship"
"Entry Level"
"Not Applicable"

Tech Stack Filter: "description" contains:
- The word "React"

More complex filters can be created to check for multiple technologies.

This cut 401 jobs down to 8 matches!

Step 3: Smart Review

For the filtered jobs:

Quick scan of title/company (10 seconds)
Open promising job_url in new tab
Check the description in detail.

Conclusion

I hope this tool helps you make your job search a slightly more enjoyable experience.

If you have any questions or feedback, please let me know.

Node.js File Writing Methods - createWriteStream vs writeFileSync

Francisco Moretti — Fri, 10 Jan 2025 09:45:46 +0000

When working with Node.js file system operations, choosing the right method to write files can significantly impact your application's performance. Let's explore two common approaches: fs.createWriteStream() and fs.writeFileSync().

Key Differences at a Glance

Feature	fs.createWriteStream(path).write(buffer)	fs.writeFileSync(path, buffer)
Synchronicity	Asynchronous	Synchronous
Blocking	Non-blocking	Blocking
Performance	Better for large files or frequent writes	Better for small, infrequent writes
Memory Usage	More memory-efficient for large files	Loads entire content into memory
Error Handling	Requires callback or event listeners	Throws errors directly
Use Case	Streaming large files, real-time data	Quick, simple writes, small files
Control Flow	Continues execution immediately	Waits until write is complete
Backpressure Handling	Handles backpressure automatically	N/A

Using createWriteStream

The stream-based approach is ideal for handling large files or when you need to write data frequently:

const fs = require('fs')

// Content to write
const content = 'Hello, Node.js file system!'

// Create a write stream
const writeStream = fs.createWriteStream('example1.txt')

// Write to the file
writeStream.write(content, 'UTF8')

// End the stream
writeStream.end()

// Handle finish event
writeStream.on('finish', () => {
  console.log('Write completed.')
})

// Handle error event
writeStream.on('error', (err) => {
  console.error('An error occurred:', err.message)
})

console.log('Program continues executing immediately.')

Key Benefits 🎯

Non-blocking operation
Memory efficient for large files
Automatic backpressure handling
Ideal for real-time data processing

Using writeFileSync

For simple, one-off writes with small files, the synchronous approach might be more straightforward:

const fs = require('fs')

// Content to write
const content = 'Hello, Node.js file system!'

try {
  // Write to the file synchronously
  fs.writeFileSync('example2.txt', content, 'UTF8')
  console.log('Write completed.')
} catch (err) {
  console.error('An error occurred:', err.message)
}

console.log('This line waits for the write operation to complete.')

Key Benefits 🎯

Simple error handling with try-catch
Predictable execution flow
Perfect for configuration files or small data writes
No callback management needed

When to Use Each Method

Choose createWriteStream when:

Working with large files
Handling real-time data streams
Memory efficiency is crucial
Non-blocking operation is required

Choose writeFileSync when:

Writing small configuration files
Simple, one-off writes
Synchronous operation is acceptable
Working with startup configurations

Conclusion

Both methods have their place in Node.js development. createWriteStream shines in scenarios involving large files or frequent writes, while writeFileSync is perfect for simple, small file operations. Choose based on your specific use case, considering factors like file size, write frequency, and performance requirements.

Color Highlighting for Tailwind CSS Variables in VS Code

Francisco Moretti — Fri, 03 Jan 2025 17:57:06 +0000

When working with Tailwind CSS variables in VS Code, having visual color indicators can significantly improve your development workflow. This is particularly useful when working with Shadcn UI components, which heavily rely on CSS variables for theming.

The Solution

Install the Color Highlight extension by Sergii N from the VS Code Marketplace
Enable HSL color highlighting by adding this to your VS Code settings.json:

{
  "color-highlight.matchHslWithNoFunction": true
}

Result

With this setup, you'll see color indicators next to your Tailwind CSS variables, making it easier to identify and work with colors in your stylesheets, especially when customizing Shadcn UI themes:

This simple configuration works with both standard CSS colors and HSL values, making your Tailwind CSS and Shadcn UI development experience more visual and intuitive.

Next.js Authentication Best Practices

Francisco Moretti — Wed, 26 Jun 2024 11:31:21 +0000

What is Next.js Authentication?

IMPORTANT: This article contains outdated advice. Next.js has significantly changed its authentication recommendations. Please refer to our updated authentication guide for current best practices.

Next.js authentication is the process of verifying user identity in Next.js applications. It ensures that only authorized users can access protected routes and data.

Authentication in Next.js is crucial for:

Protecting sensitive user data
Controlling access to specific features
Personalizing user experiences
Maintaining application security

Understanding Next.js authentication best practices is key to building secure and efficient web applications.

Middleware vs. Page Component Authentication

Next.js provides two main approaches to authentication: middleware and page component authentication. Let's explore both:

Middleware Authentication

Middleware authentication offers several advantages:

Cleaner structure for managing authentication across routes
Preserves static rendering capabilities
Better performance, especially with JSON Web Tokens (JWTs)

Here's a simple example of middleware authentication:

import type { NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
  const currentUser = request.cookies.get('currentUser')?.value

  if (currentUser && !request.nextUrl.pathname.startsWith('/dashboard')) {
    return Response.redirect(new URL('/dashboard', request.url))
  }

  if (!currentUser && !request.nextUrl.pathname.startsWith('/login')) {
    return Response.redirect(new URL('/login', request.url))
  }
}

export const config = {
  matcher: ['/((?!api|_next/static|_next/image|.*\\.png$).*)'],
}

Page Component Authentication

Page component authentication has its own benefits:

Can be implemented directly in the page file
Offers more flexibility for page-specific auth logic

Here's an example of page component authentication:

import { redirect } from 'next/navigation';
import { checkAuth } from '@/lib/auth';

export default async function ProtectedPage() {
  const isAuthenticated = await checkAuth();
  if (!isAuthenticated) {
    redirect('/login');
  }
  return (
    <div>
      <h1>Protected Content</h1>
      {/* Page content here */}
    </div>
  );
}

💡 Tip: Choose middleware for better performance and cleaner code structure, especially for apps with many protected routes.

Avoiding Authentication in Layout Components

It's important to avoid implementing authentication checks in layout components. Why? Layout components don't re-render on client-side navigation, which could leave routes unprotected.

Preserving Static Rendering

Static rendering is a key performance feature in Next.js. To preserve it:

Use middleware for authentication when possible
Don’t add authentication inside specific routes (pages).

Adding authentication inside a page makes it dynamic. However, many times the extra security layer benefit outweighs the performance improvement.

Authentication for Server Actions

Server actions are a new feature in Next.js that allow server-side processing directly from client components. When using server actions:

Implement authentication checks within the server action itself
Don't rely solely on page-level or middleware authentication

Server actions are like API routes. They could be called by an external user by calling the server action URL directly.

Proximity Principle

The proximity principle suggests keeping authentication checks as close as possible to where data is accessed or used. This means:

Implementing checks in reusable components that handle sensitive data
Adding auth logic directly in data fetching functions

Here's an example of applying the proximity principle:

async function fetchUserData(userId: string) {
    const isAuthenticated = await checkAuth();
  if (!isAuthenticated) {
    throw new Error('Unauthorized');
  }

  // Fetch and return user data
}

Multi-layered Approach

A robust authentication strategy in Next.js involves multiple layers of protection:

Use middleware or page-level checks as a first line of defense
Implement additional checks at the page and data access levels

Here's a simplified example of a multi-layered approach:

// Middleware (first layer)
export function middleware(request: NextRequest) {
  // Check for auth token
}

// Page component (second layer)
export default function ProtectedPage() {
  const { user } = useUser(); // Custom hook for user data
  if (!user) return <LoadingOrRedirect />;

  return <ProtectedContent user={user} />;
}

// Data fetching (third layer)
async function fetchSensitiveData() {
  // Check auth and permissions before fetching
}

Conclusion

Next.js authentication best practices involve a combination of techniques:

Use middleware for app-wide auth when possible
Implement page-level checks for specific routes
Apply the proximity principle for data access

References

Server Side Rendering Vs Client Side Rendering Waterfall

Francisco Moretti — Thu, 20 Jun 2024 11:16:16 +0000

What is Server Side Rendering (SSR)?

Server-side rendering (SSR) is a technique where the initial HTML of a web page is generated on the server and sent to the client's browser. This approach allows for faster initial page loads and better search engine optimization (SEO) since search engines can easily crawl and index the rendered content.

What is Client Side Rendering (CSR)?

Client-side rendering (CSR) is a technique where the initial HTML of a web page is minimal, and the content is rendered dynamically on the client-side using JavaScript. This approach can provide a more seamless and interactive user experience, but it may result in slower initial page loads and potential SEO challenges.

The Waterfall Effect

The waterfall effect refers to the sequence of network requests and responses required to load a web page fully. Each request must wait for the previous one to complete, creating a cascading effect similar to a waterfall.

Client-Side Rendering Waterfall

In a client-side rendered React application, the waterfall effect can be more pronounced due to the multiple round trips required to fetch the necessary JavaScript files and data. Let's consider an example with a Post component and a child Comment component:

Initial Markup (without content): The browser receives the initial HTML markup, which contains placeholders for the React components.
Get the Post JS: The browser fetches the JavaScript file(s) required to render the Post component.
Get the Post content: Once the Post component is loaded, the browser fetches the data required to render the post content.
Get the Comment JS: The browser fetches the JavaScript file(s) required to render the Comment component.
Get the Comment content: Finally, the browser fetches the data required to render the comment content.

This process results in a waterfall with five distinct steps, potentially leading to longer load times and a perceived delay in rendering the complete page.

Server-Side Rendering Waterfall

In contrast, with server-side rendering, the waterfall effect can be significantly reduced. Here's how it might look for the same Post and Comment components:

Markup (with content): The server generates and sends the initial HTML markup with the rendered content for both the Post and Comment components.
Get in parallel:
- The Post JS: The browser fetches the JavaScript file(s) required for the Post component.
- The Comment JS: The browser fetches the JavaScript file(s) required for the Comment component.

By rendering the initial content on the server, the waterfall is reduced to just two steps, potentially resulting in faster initial page loads and improved perceived performance.

Conclusion

The choice between server-side rendering (SSR) and client-side rendering (CSR) in React applications can significantly impact performance, particularly when considering the waterfall effect. SSR generally results in a shorter waterfall and faster initial page loads, while CSR may be easier to achieve, it can have a longer waterfall.

RunJS - A JavaScript and TypeScript Local Playground

Francisco Moretti — Fri, 07 Jun 2024 09:24:57 +0000

Intro

Recently, I got a license from Luke Haas to explore RunJS, and I'm impressed with some of the features. I've been putting it to the test and integrating it into my workflow. It's worth mentioning that there is a free version with core functionality, and the license gives you lifetime access (with updates for 1 year), which is rare these days. In this post, I'll be sharing my experience with RunJS and how it's helping me in my daily work.

What is RunJS?

RunJS is a local playground for JavaScript and TypeScript. It allows you to write, execute, and see the results of your code instantly. Unlike IDEs, RunJS has a minimalistic, distraction-free interface perfect for quick experiments and learning.

Why Choose RunJS?

Minimalistic Interface: RunJS offers a clean, distraction-free environment. This simplicity helps you focus on your code, making it great for presentations and screen sharing.
Continuous Code Execution: RunJS continuously executes your code as you type. This instant feedback loop is invaluable for testing and learning.
Run JS and TS with no configuration: RunJS supports both JavaScript and TypeScript out of the box. No need to run node or to setup TS. It simply works.

Use cases for RunJS

These are some of the use cases that I've personally found useful.

1. Exploring JS Language Features

JavaScript is weird. RunJS helps you understand them by letting you execute code snippets instantly. This is great for trying out language features or understanding tricky parts of JavaScript.

Note that it highlights some of these errors to help you avoid the fitfalls of JavaScript.

2. Printing the Output of Code Execution

RunJS makes it easy to see the output of your code as you type. This feature is perfect for debugging and understanding how your code works.

3. Executing JS/TS Without Creating a File

With RunJS, there's no need to create files or set up a Node environment to run your code. This is ideal for quick experiments or learning sessions.

4. Solving LeetCode Problems

This is my favorite use case for RunJS. RunJS allows you to print the output of test cases and different parts of the code easily, making debugging and understanding your solution much simpler. The distraction-free interface of RunJS helps a lot here.

You can code all the function with auto-completion support and error linting. It's also convenient to see the output of all the test cases at the end and check how they do without having to hit run every time.

Super helpful for small problems like this one.

Showing another small one that fits in the screen, but it's also helpful for complex problems.1

Oh and you might have noticed that the last case should be true. Wrong! This is not how array comparison works in JS. Here RunJS is helping you to understand the problem with an error message.

Conclusion

RunJS is a nice tool for JavaScript and TypeScript coding. Its simple interface and instant feedback make it perfect for learning, and prototyping. It's not going to replace your IDE but it can be a great addition to your workflow. By being different, and by keeping things simple, it does better than IDEs for some tasks. In my opinion, is a specialized tool that helps with communication, exploring and focus.

useState vs useRef - When to use state and when to use ref

Francisco Moretti — Tue, 21 May 2024 12:40:45 +0000

What is useState?

useState is a React hook used for managing state in functional components. It allows you to add state to your components, making them dynamic and interactive.

Key Features of useState

State Management: useState helps manage state within a component.
Re-renders on Change: The component re-renders when the state changes.
Batched Updates: React batches multiple state updates for performance.

Example using useState

Here’s a simple counter that increments when a button is clicked.

import React, { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);

  const increment = () => {
    setCount(count + 1);
  };

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={increment}>Increment</button>
    </div>
  );
}

export default Counter;

In this example, useState initializes the count at 0 and updates it each time the button is clicked, causing the component to re-render.

What is useRef?

useRef is another React hook, primarily used for accessing and manipulating DOM elements directly. It persists values between renders without causing re-renders.

Key Features of useRef

DOM Reference: Provides a way to reference and interact with DOM elements.
No Re-renders on Change: Changing the ref value does not trigger a re-render.
Persistent Values: Keeps the same object reference between renders.

Example using useRef

Here’s an example where clicking a button focuses an input field.

import React, { useRef } from 'react';

function FocusInput() {
  const inputRef = useRef(null);

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

  return (
    <div>
      <input ref={inputRef} type="text" />
      <button onClick={focusInput}>Focus Input</button>
    </div>
  );
}

export default FocusInput;

In this example, useRef creates a reference to the input element, allowing direct DOM manipulation to focus the input field when the button is clicked.

useState vs useRef: A Comparison 🔍

Let's compare useState and useRef based on several aspects.

Aspect	useState	useRef
Purpose	State management	DOM reference
Return value	Returns `[value, setValue]`	`{ current: initialValue }`
Initial value	Required	Optional
Re-render on change	Yes	No
Mutablility	Mutable	Immutable
Update trigger	Function call	Direct mutation of current
Usage in rendering	Yes	No
Async updates	Batched	Immediate
Hook type	State hook	Ref hook
Common use case	Managing component state	Accessing/manipulating DOM elements

When to Use useState

Managing dynamic values that impact the UI.
Triggering re-renders to reflect state changes.

When to Use useRef

Accessing or modifying DOM elements directly.
Storing mutable values that persist across renders without causing re-renders.

Conclusion

Understanding the differences between useState and useRef is crucial for effective state management and DOM manipulation in React. Use useState when you need stateful logic that affects rendering. Use useRef for accessing DOM elements and persisting values without causing re-renders.

What is React Hydration

Francisco Moretti — Tue, 30 Apr 2024 08:51:07 +0000

Understanding React Hydration

React hydration is the process of taking a server-rendered HTML page and connecting the client-side JavaScript to it, adding interactivity and application state. Here's a step-by-step explanation:

Server-side Rendering: Server-side rendering involves generating the initial HTML content for the web page using React. This HTML is static and lacks interactivity.
Sending HTML to the Client: The server sends the pre-rendered HTML to the client's web browser.
Hydration on the Client: When the client receives the HTML, React's hydration process kicks in. The hydrateRoot() function is used to "hydrate" the static HTML by attaching event listeners, state, and other interactivity to the existing DOM elements.
Reusing the Existing DOM: During hydration, React tries to reuse the existing DOM nodes instead of creating new ones. It compares the server-rendered HTML with the virtual DOM and updates only the necessary parts.
Interactivity: After hydration, the web page becomes interactive. Users can now trigger events, update the UI, and interact with the application just like a traditional client-side rendered React app.

Improved Performance

Hydration allows for faster initial load times compared to a traditional client-side rendered app, as the server has already generated the initial HTML. The client-side JavaScript then enhances the experience by adding interactivity.

In summary, React hydration is the process of transforming a static, server-rendered HTML page into an interactive, client-side rendered React application, seamlessly connecting the two environments for a better user experience.