Pointer events, not mouse events

The first version of every comparison slider on the internet listens to mousedown, mousemove and mouseup. Then someone opens it on a phone and nothing happens, so touchstart and touchmove get bolted on, and now there are two code paths that drift apart.

Pointer events replace both. onPointerDown, onPointerMove and onPointerUp fire for mouse, touch and pen with the same event shape, and clientX means the same thing in all three. The one extra call that makes dragging reliable is setPointerCapture: once the visitor presses down, the element keeps receiving move events even when the finger or cursor leaves its box. Without it, a fast drag that exits the frame freezes the handle halfway.

const onPointerDown = (e: React.PointerEvent<HTMLDivElement>) => {
  e.currentTarget.setPointerCapture(e.pointerId);
  setDragging(true);
  fromClientX(e.clientX);
};
const onPointerMove = (e: React.PointerEvent<HTMLDivElement>) => {
  if (!dragging) return;
  fromClientX(e.clientX);
};
const onPointerUp = (e: React.PointerEvent<HTMLDivElement>) => {
  if (e.currentTarget.hasPointerCapture(e.pointerId)) e.currentTarget.releasePointerCapture(e.pointerId);
  setDragging(false);
};

fromClientX reads the container's bounding rect and converts the pointer position into a percentage between 0 and 100. That percentage is the only piece of state. Everything else, the clip, the handle position, the ARIA attributes, derives from it.

Listen on the whole frame, not just the handle. Visitors tap anywhere on the photo and expect the handle to jump there. A 24 pixel handle as the only hit target is a usability bug on touch screens.

The clip-path reveal

The after photo fills the frame. The before photo sits on top of it in an absolutely positioned layer, and clip-path: inset(0 X% 0 0) cuts that layer off on the right at the handle position. Dragging changes X and the before photo reveals or hides the after photo underneath.

Clip-path is the right tool because the two images never move or resize. A common alternative is to change the width of the top layer, which stretches the image unless you also counter-scale it, and that path leads to subpixel jitter during a drag. With clip-path both images stay pixel aligned and the browser only repaints the clipped region.

In the Facade component the value runs through a useSpring from motion/react and useTransform turns the spring into the clip string. The trick is in one effect: while dragging, the spring jumps straight to the value so the handle follows the finger one to one; when the visitor releases or taps somewhere, the spring eases to the new position. Reduced motion users get the jump in both cases.

const spring = useSpring(value, { stiffness: 400, damping: 38, mass: 0.6 });
const clip = useTransform(spring, (v) => `inset(0 ${100 - v}% 0 0)`);

React.useEffect(() => {
  if (dragging || reduce) spring.jump(value);
  else spring.set(value);
}, [value, dragging, reduce, spring]);

Keyboard support with arrow keys

A slider that only works with a pointer is a slider half the audience cannot use. Keyboard support is a single handler on the focusable handle, and it follows the conventions people already know from range inputs:

• Left and Down move the handle toward "before", Right and Up toward "after", by step percent. The default step is 2.
• Shift multiplies the step by 5, so a held shift arrow sweeps the frame in a few presses.
• Page Up and Page Down move by 10.
• Home jumps to 0 and End to 100, the two states a visitor most wants to compare.

Call preventDefault on the keys you handle so the page does not scroll when someone presses Down with the handle focused. Do not handle keys you do not use; Tab must keep working.

The ARIA slider role

Screen reader support is where I see the most comparison sliders fail, and it is not much work. The handle is the one element in the tab order, and it carries:

• role="slider" with aria-valuemin={0}, aria-valuemax={100} and aria-valuenow set to the rounded value.
• aria-valuetext that reads as a sentence, like "60% before, 40% after", so the announcement means something. A bare "60" does not.
• aria-label from the label prop, defaulting to "Before and after comparison", so a page with three sliders announces which one has focus.

The two images are not decorative. When you pass beforeSrc and afterSrc, each layer renders an <img> with the beforeAlt and afterAlt text, because "Roof before replacement, missing shingles on the south side" is information a sighted visitor gets from the photo. The illustrated fallback that renders without URLs uses role="img" with the same labels.

Touch handling on mobile

Three things break comparison sliders on phones, and all three are fixable with CSS and one attribute.

First, scrolling. A horizontal drag on a touch screen is also a scroll gesture, and the browser will happily scroll the page while you try to move the handle. touch-action: none on the frame tells the browser that this element owns its touches. Only set it on the slider, never on the page.

Second, selection. A long press selects the image or the labels. user-select: none on the frame prevents it.

Third, the handle size. The visual handle can be slim, but the hit area is the entire frame thanks to the pointer handlers above, so a thumb never has to land on a two pixel line. The handle itself still gets a 44 pixel circle so it reads as something to grab.

Install and use

The slider is a Pro item and installs from the private registry once your license key is in components.json (one time setup in the installation docs):

npx shadcn@latest add @facadeui/before-after-slider

import { BeforeAfterSlider } from "@/components/facade/before-after-slider";

export function RoofProject() {
  return (
    <BeforeAfterSlider
      beforeSrc="/projects/elm-street/before.jpg"
      afterSrc="/projects/elm-street/after.jpg"
      beforeAlt="Roof before replacement, curling shingles and moss on the north slope"
      afterAlt="Roof after replacement, new architectural shingles and copper flashing"
      beforeLabel="Before"
      afterLabel="After"
      defaultValue={50}
      step={2}
      label="Elm Street roof replacement"
      onValueChange={(v) => console.log(v)}
      className="max-w-3xl"
    />
  );
}

Shoot the two photos from the same spot with the same lens, or the reveal shows a misaligned house instead of a transformed roof. A tripod mark on the driveway is enough. On the roofer page the slider sits directly under the hero, before the stats, because a roofer's work is the proof and the proof should come before the claims.

FAQ

Can I use it for staging photos in real estate?

Yes. Empty room before, staged room after, same camera position. It works for renovations, landscaping, dental smile makeovers and anything else with a credible before state. It does not work for stock photos, and visitors can tell.

Does it work with next/image?

The beforeSrc and afterSrc props take plain URLs and render standard images. If you need next/image for sizing and formats, the source is yours after installation; swap the two <img> elements and keep the alt text in place.

Why a 16 by 10 frame?

The frame uses aspect-ratio so both photos share one box regardless of their native size, and 16 by 10 fits most exterior and interior shots without cropping the roofline. Override it with a Tailwind aspect-* class through className.

Why new Date() on the client is wrong

new Date() gives you the visitor's local time. A visitor in Los Angeles looking at a barber in New York gets a Date whose getHours() is three hours behind the shop. Compare that to the shop's hours and the badge is wrong for every out of town visitor, which on a site that ranks for the city name is most of them.

The server is no better. On Vercel or any cloud host the server clock is UTC or whatever region the function runs in. If you render "Open now" on the server, you render it in the server's zone, and the first paint in the browser disagrees with the hydrated one.

The rule that fixes both: the business has one time zone, it lives in your data, and every comparison happens in that zone. The visitor's zone and the server's zone are irrelevant.

Intl and the business time zone

You do not need a date library for this. Intl.DateTimeFormat accepts a timeZone option and formatToParts gives you the weekday, hour and minute in that zone as separate strings. Turn them into a weekday index and minutes since midnight and you have everything a comparison needs:

export function getZonedNow(date: Date, timeZone: string): { day: number; minutes: number } {
  const parts = new Intl.DateTimeFormat("en-US", {
    timeZone,
    weekday: "short",
    hour: "numeric",
    minute: "numeric",
    hourCycle: "h23",
  }).formatToParts(date);
  const get = (type: Intl.DateTimeFormatPartTypes) => parts.find((p) => p.type === type)?.value ?? "0";
  const day = ["Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"].indexOf(get("weekday"));
  const minutes = (Number(get("hour")) % 24) * 60 + Number(get("minute"));
  return { day, minutes };
}

hourCycle: "h23" asks for 0 to 23 hours, and the % 24 guards against engines that still return "24" for midnight. The Date you pass in is the real current instant; only its presentation changes. This is the whole trick: one instant, interpreted in the shop's zone.

Both Facade components use exactly this function. The badge even exports it along with getOpenStatus, so you can compute the status for a schema.org openingHoursSpecification or a "Closes in 20 minutes" line elsewhere on the page.

Split shifts and closed days

Hours data is where most components give up. A salon opens 9 to 1 and 2 to 7. A restaurant closes Mondays. A clinic is open Saturday morning only. The data shape has to express all of that without special cases in the UI.

Facade uses a weekly map where each day holds an array of ranges. Missing, null or an empty array means closed. More than one range means a split shift:

import type { WeeklyHours } from "@/components/facade/opening-hours";

export const hours: WeeklyHours = {
  mon: null,
  tue: [{ open: "09:00", close: "13:00" }, { open: "14:00", close: "19:00" }],
  wed: [{ open: "09:00", close: "13:00" }, { open: "14:00", close: "19:00" }],
  thu: [{ open: "09:00", close: "20:00" }],
  fri: [{ open: "09:00", close: "19:00" }],
  sat: [{ open: "08:00", close: "16:00" }],
  sun: null,
};

Times are 24 hour strings. They get parsed into minutes since midnight once, then every comparison is integer math. The list renders "Closed" for a null day and joins the ranges of a split day with a comma. A range that closes after midnight, like a bar open until 02:00, is handled by treating a close time earlier than the open time as belonging to the next day.

Highlighting today

Visitors scan the list for one row: today. Highlighting it is the single most useful thing the component does, and it has to use the business zone too. At 11 pm in New York it is already Tuesday in Zurich, so "today" for the Zurich salon is Tuesday.

The component gets today's index from the same getZonedNow call and renders a soft pill behind that row. The pill is a motion.div with a layoutId, so if the page stays open past midnight it slides to the next row instead of jumping. The row also gets aria-current="date" so screen readers know which day the highlight means.

Before the component mounts there is no "today". The component keeps now as null on the first render, renders the plain list with a "Loading" status, and fills in today and the status in an effect. That is what makes the server HTML and the first client render identical, which is the hydration mismatch I ran into on that salon site.

The weekStartsOn prop switches between a Monday first and a Sunday first list. Europe reads Monday first, US customers often expect Sunday first.

Live open status without a server

The open status is derived, not fetched. Every 30 seconds an interval updates now, the component recomputes "is there a range on today that contains the current minute", and the badge flips when the shop opens or closes while the page is open. No API call, no server, no cron.

The standalone badge adds a third state. With closingSoonMinutes set, it turns amber and reads "Closing soon" during the last stretch before close. The default is 60 minutes. For a restaurant that stops seating at 9 pm but closes at 10, pass the seating time as the close and keep the default.

Both components are free and MIT licensed:

npx shadcn@latest add https://facadeui.com/r/opening-hours.json https://facadeui.com/r/open-now-badge.json

And together on a page, sharing one hours object:

import { OpeningHours } from "@/components/facade/opening-hours";
import { OpenNowBadge } from "@/components/facade/open-now-badge";
import { hours } from "@/data/hours";

export function HoursSection() {
  return (
    <section className="grid gap-6 md:grid-cols-[1fr_320px]">
      <div>
        <OpenNowBadge hours={hours} timeZone="Europe/Zurich" closingSoonMinutes={45} size="md" />
        <h2 className="mt-4 text-3xl font-semibold">Visit the salon</h2>
      </div>
      <OpeningHours
        hours={hours}
        timeZone="Europe/Zurich"
        weekStartsOn="mon"
        title="Hours"
        note="Closed on public holidays."
      />
    </section>
  );
}

The badge belongs in the hero next to the phone number and in the sticky mobile bar. The full list belongs in the contact section and the footer. I use this exact pairing on the salon page, where "Are you open Sunday?" is the question that decides whether someone calls.

FAQ

What about holidays?

Holidays are exceptions, not a schedule, so they do not belong in WeeklyHours. Keep a small list of dates with their override hours in your data, pick today's override in the business zone, and pass the result as hours. The note prop is the place to tell visitors that holiday hours differ.

Does it work for businesses in several locations?

Yes. Each location has its own hours object and its own timeZone string. Render one OpeningHours per location, or one badge per location card. Nothing is shared globally.

Why not render the status on the server for SEO?

Search engines do not index "Open now" as a ranking signal, and a server rendered status would be wrong by the time the page is crawled anyway. Put the schedule itself in openingHoursSpecification JSON-LD, which is what Google reads, and let the live status be a client concern.

Why themes age badly

A theme is one decision made for you, forever. Layout, typography, animation library, form handler and color system arrive as a single bundle. The day you want to change one of them you discover they are all tied together.

Three problems show up on the themed real estate sites I get asked to fix:

• The listing data is shaped for the theme's demo, not for the MLS feed or the spreadsheet the agent actually has. Mapping one to the other becomes a permanent chore.
• The animations are decorative. Things fade in, but nothing on the page responds to the visitor. A buyer who wants to filter by price gets a page reload.
• Lead capture is a generic contact form. Sellers who want to know what their home is worth are the most valuable visitors on the site, and the form treats them like someone asking about parking.

Blocks solve this because each block is a single TypeScript file in your repo. You install the ones you need, pass your data as props, and edit the source when a client wants something specific. There is no theme to update.

The 10 block page plan

This is the block order for an agent site. It is the same order I use on the real estate agent page, and each block links to its component docs.

1. Hero, real estate: a full width hero with a Buy, Rent, Sell search panel and animated stats. The search mode changes the labels, so "Location" becomes "Your address" when a visitor switches to Sell and the button turns into "Get valuation".
2. Agent card: the agent's name, rating, license and languages, with call, email and tour actions. On an agent site this belongs above the fold on mobile.
3. Property listing grid: filterable and sortable listings with saved homes and a Load more button. The grid re-layouts with a spring when a filter changes instead of blinking.
4. Stats band: four animated numbers. Homes sold, average days on market, years in business, neighborhoods covered. Use real numbers from the agent or leave the block out.
5. Testimonials wall: reviews with names and neighborhoods.
6. Home valuation funnel: the seller lead magnet. Five steps, address first, estimate range at the end.
7. Mortgage calculator: the buyer tool. I covered the formula and the install in a separate article.
8. FAQ section with FAQPage JSON-LD.
9. Contact section with a form, hours and a map card.
10. Big footer with NAP details, hours and the brokerage license line.

Ten blocks is the whole site. A neighborhood page reuses blocks 3, 4 and 8 with different data.

The data shape for listings

Before you touch the hero, decide what a listing looks like in code. The listing grid takes a PropertyListing[] array, and every other block that shows property data can be fed from the same records.

import type { PropertyListing } from "@/components/facade/property-listing-grid";

export const listings: PropertyListing[] = [
  {
    id: "mls-4108",
    type: "house",
    title: "Modern farmhouse with pool",
    address: "4108 Avenue G",
    city: "Hyde Park, Austin",
    price: 1_285_000,
    beds: 4,
    baths: 3.5,
    sqft: 3120,
    daysOnMarket: 2,
    status: "New",
    href: "/listings/mls-4108",
    imageSrc: "/photos/mls-4108/cover.jpg",
  },
];

Two decisions in that shape matter later. type is a union of "house" | "condo" | "townhome" because the filter chips in the grid are built from it. status is optional and limited to "New" | "Open house" | "Price drop" | "Pending", because a badge vocabulary that grows without limit ends up with twelve colors nobody can read.

Where does the array come from? For a solo agent with twenty listings, a JSON file in the repo, updated through a CMS or a spreadsheet export, costs nothing. For a brokerage with an MLS feed, a server component fetches the feed, maps it to PropertyListing once, and passes the array down. The grid does not care which.

Rendering the grid is one component:

import { PropertyListingGrid } from "@/components/facade/property-listing-grid";
import { listings } from "@/data/listings";

export function Listings() {
  return (
    <PropertyListingGrid
      eyebrow="Featured homes"
      heading="Homes on the market this week"
      listings={listings}
      pageSize={6}
      defaultSort="newest"
      onToggleSave={(id, saved) => console.log(id, saved)}
    />
  );
}

Saved homes live in component state. To survive a reload, write to localStorage in onToggleSave; restoring the set on load is a small edit to the installed source.

The lead capture flow

A real estate site has two visitors with two different questions. Buyers ask "Can I afford this?" and sellers ask "What is my home worth?" Each gets its own block, and the two blocks hand leads to the same place.

The valuation funnel asks for the address first. That ordering is deliberate: an address is low commitment and feels like the start of a tool, not the start of a form. Property type, size and condition follow, and the contact details come last, after the visitor has invested a minute. The built-in estimator multiplies square footage by a basePricePerSqft you set for the market, adjusts for condition, and returns a low, mid and high figure. It is clearly labeled as an estimate, not an appraisal, and the estimate prop lets you swap in a real valuation API later without touching the UI.

import { ValuationFunnel } from "@/components/facade/valuation-funnel";

<ValuationFunnel
  marketLabel="Austin, TX"
  basePricePerSqft={312}
  onLead={(data, estimate) => fetch("/api/leads", { method: "POST", body: JSON.stringify({ data, estimate }) })}
  bookLabel="Book a walkthrough"
  bookHref="/book"
/>

onLead is where the site earns money. I post to a route handler that writes the lead to the agent's CRM and sends a notification. The mortgage calculator's onChange callback is the buyer side of the same idea: when a buyer settles on a payment, the pre-approval button next to the donut already knows the numbers.

Install and deploy on Vercel

All four featured blocks are Pro items. Set up the private registry once with your license key (the one time setup is in the installation docs), then install the page in a single command:

npx shadcn@latest add @facadeui/hero-real-estate @facadeui/property-listing-grid @facadeui/valuation-funnel @facadeui/mortgage-calculator

The free blocks on the list, agent card, stats band, FAQ section and the footer, install from the public registry URL, for example npx shadcn@latest add https://facadeui.com/r/agent-card.json. Every file lands in components/facade/, depends only on motion and lucide-react, and uses the semantic Tailwind tokens your shadcn setup already defines. Change --brand in globals.css and the whole site re-themes.

Deploying is vercel from the project root or a Git push. Because listings can render on the server, the listing pages are static HTML with the interactive grid hydrating on top. That is what keeps Largest Contentful Paint inside Google's 2.5 second "good" threshold on a phone, which a theme loading several jQuery plugins rarely manages.

FAQ

Is this a template I can download as a zip?

No. It is an ordered set of blocks you install into your own Next.js project with the shadcn CLI. You get the same result as a template, a complete page, but every section is a file you own and can edit. The order and the data shapes are documented on the industry page.

Can I connect an IDX or MLS feed?

Yes. Fetch the feed in a server component, map each record to the PropertyListing type and pass the array to the grid. The grid has no opinion about where the data comes from. IDX compliance rules about attribution and refresh intervals are between you and your MLS.

Does it work with the Pages Router or only the App Router?

The blocks are plain React client components. They work in the App Router, the Pages Router, Vite and Remix, as long as Tailwind v4 and the shadcn tokens are set up. The install docs use the App Router because that is what new Next.js projects start with.

The payment formula, explained once

A fixed rate mortgage payment is one formula. Everything else in the component is presentation.

With a loan amount P, a monthly interest rate r (the annual rate divided by 12 and by 100) and a number of monthly payments n (years times 12), the monthly principal and interest payment is:

M = P * r * (1 + r)^n / ((1 + r)^n - 1)

Two edge cases matter in code. When the rate is zero, the formula divides by zero, so you return P / n instead. When the down payment reaches 100 percent, the loan amount is zero and the payment is zero. Both happen the moment a visitor drags a slider to the end, so handle them before you touch any animation.

In TypeScript:

export function monthlyPayment(loan: number, annualRate: number, years: number) {
  const n = years * 12;
  if (loan <= 0) return 0;
  if (annualRate === 0) return loan / n;
  const r = annualRate / 100 / 12;
  const f = Math.pow(1 + r, n);
  return (loan * r * f) / (f - 1);
}

Principal and interest are only part of what a buyer pays each month. US buyers expect property tax, homeowners insurance and, for condos, HOA dues on the same screen. Tax is an annual percentage of the home price divided by 12. Insurance is an annual dollar amount divided by 12. HOA is already monthly. The total is the sum of the four, and that total is the number the visitor remembers.

Controlled inputs with sliders

The calculator has four inputs: home price, down payment, interest rate and loan term. The first three are range inputs with the formatted value printed next to the label, so a buyer always sees the exact number the slider is on. If you add a text input next to each slider, make both controls write to the same piece of state, which keeps them in sync without effects.

Down payment is the input that trips people up. Buyers think in percent, lenders think in dollars, and the slider has to show both. Store the percent, derive the dollar amount, and clamp the percent between 0 and 50 so the slider stays useful. A 90 percent down payment is technically valid and practically never happens.

A few details that make the inputs feel right:

• Format the displayed values with Intl.NumberFormat, not with string concatenation. $1,250,000 reads, $1250000 does not.
• Pick a sensible step for the price slider, a few thousand dollars at least. Pixel precision on a 2 million dollar range is useless.
• Label every range with a visible <label> and an aria-valuetext that reads the formatted value. Screen readers announce "650,000 dollars", not "650000".

The 15 or 30 year term toggle

Most calculators put the term in a select. A segmented toggle with two options is faster and shows both choices at once. In Facade it is a small two button group that moves a sliding pill behind the active option, and the payment re-renders the moment it changes. Buyers click it back and forth to feel the difference, which is exactly what you want them doing on a listing page.

Under the hood it is a role="radiogroup" with two role="radio" buttons, arrow keys to switch, and the defaultTerm prop set to 15 or 30. Nothing fancy, but the arrow keys matter: a toggle that only works with a mouse is a bug.

A donut breakdown with motion

A single total hides where the money goes. The donut shows four segments: principal and interest, tax, insurance and HOA. Each segment is an SVG circle with a strokeDasharray for its share and a strokeDashoffset to position it after the previous segment.

Animating the segments is where motion/react earns its place. Each circle's strokeDasharray and strokeDashoffset are animated when the values change, so dragging the price slider makes the segments breathe instead of jumping. The total in the middle of the donut uses the same count-up logic as the free Animated counter: it tweens from the previous value to the new one over a few hundred milliseconds, formatted as currency on every frame.

Two rules I follow for this kind of animation:

• Animate on change, not on mount only. The first render can animate in, but the interesting moment is the slider drag.
• Respect prefers-reduced-motion. useReducedMotion() from motion returns true for those visitors, and the component then sets values directly instead of springing to them.

Install it with the shadcn CLI

The Mortgage calculator is a Pro item, so it installs from the private registry once your license key is in components.json (the installation docs show the one time setup).

npx shadcn@latest add @facadeui/mortgage-calculator

Then drop it on a listing page with the listing's price as the default and your market's tax rate:

import { MortgageCalculator, type MortgageBreakdown } from "@/components/facade/mortgage-calculator";

export function ListingPayment({ price }: { price: number }) {
  return (
    <MortgageCalculator
      defaultPrice={price}
      defaultDownPercent={20}
      defaultRate={6.5}
      defaultTerm={30}
      propertyTaxRate={1.1}
      annualInsurance={1800}
      monthlyHoa={0}
      title="Estimate your monthly payment"
      onChange={(result: MortgageBreakdown) => {
        // result.total, result.principalAndInterest, result.propertyTax, result.insurance, result.hoa, result.loanAmount
      }}
    />
  );
}

The onChange callback hands you the full breakdown on every change. I use it to update a "Payment from $X per month" line in the sticky header of the listing page, and some agents use it to prefill a pre-approval request.

If you only need the count-up number without the calculator, the Animated counter is free and MIT licensed:

npx shadcn@latest add https://facadeui.com/r/animated-counter.json

Where it belongs on a real estate site

On a listing page, the calculator goes directly under the key facts, before the photo gallery ends and the agent card appears. Buyers scroll to the price, then to the payment, then decide whether to keep reading. On a brokerage home page it earns less, because there is no price to anchor it to. The block order I use for agent sites is on the real estate agent page.

One thing I do not do: pull live rates from an API. Rates change daily, the calculator becomes a compliance question, and buyers understand that 6.5 percent is an example. Set a sensible default, let them change it, and put a one line disclaimer under the donut.

FAQ

Does the calculator include PMI?

No. Private mortgage insurance depends on the lender and the loan program, and a wrong PMI number is worse than none. If your market needs it, add it as a fifth monthly line in the onChange consumer or extend the component; the source is yours after installation.

Can I use it outside the US?

Yes. The formula is universal for fixed rate loans. Pass monthlyHoa={0}, set propertyTaxRate to your local rate or 0, and format currency with your own Intl locale in the consuming component. The labels are props, so "HOA" can become "Service charge" or disappear.

Why not use a mortgage calculator embed from a lender?

Embeds load a third party script, carry the lender's branding, and often break Core Web Vitals on mobile because they inject an iframe above the fold. A component you own renders as part of the page, inherits your theme tokens and sends leads to you, not to the lender.