Forem: Alex

How I Built state-in-url: My Journey Turning the URL Bar into Real React State

Alex — Mon, 13 Apr 2026 13:39:54 +0000

I'm the developer behind state-in-url. The library lets you put real JavaScript values - numbers, Date objects, nested arrays, objects - directly into browser query parameters. It keeps full TypeScript support throughout. The hook behaves exactly like useState, but the state lives in the URL. It survives reloads. You can share the link and nothing gets lost.

Try the live demo at https://state-in-url.dev

Type in the form. Watch the URL change instantly. Refresh the page. The data stays exactly as you left it. The example sits right in the repo too.

This project grew from a frustration I hit again and again while working on dashboards and larger forms. State ended up split across local variables, a store, and the URL for sharing. Other libraries came close, yet they always added too much setup or turned everything into strings and dropped my types. I decided to build the version I actually wanted to use every day.

The repo now sits at 400+ stars on GitHub. Version 6.1.2 shipped a few weeks ago. It still surprises me that people use it. Here is the full story - the frustrations, the choices that worked, the testing struggles, and what stayed with me afterward.

The Problem

You have probably faced this situation. A page holds filters or a detailed form. State lives in three places at once. Local component values. Maybe a store. Plus the URL so users can bookmark or share their exact view. Syncing it all felt like constant extra work.

I wanted the hook to stay dead simple. Return state and a setter, just like useState, but with TypeScript awareness of the exact shape. Real data types that survive the URL round trip. Clean support for Next.js App Router with SSR, plus React Router and Remix. No interference with other query parameters. And keep the whole thing tiny - zero runtime dependencies, under 2 KB gzipped.
That became my starting point in spare time.

The solution

The choice I remain happiest about is straightforward. I used one plain JavaScript object for both default values and the type definition. Without separate schema or heavy generics. You write code like this

export const formState = {
 name: '',
 age: undefined as number | undefined,
 agree_to_terms: false,
 tags: [] as { id: string; value: { text: string; time: Date } }[],
} as const;

type FormState = typeof formState;

Pass that object to the hook and everything flows. Types and defaults work out of the box.
For shared state with useSharedState, I relied on a single JavaScript object. Components subscribe to changes, without React Context. It handled cases where unrelated parts of the app needed the same data without added complexity.
The encoder and decoder required some tuning. The goal was a readable URL that still preserved real types. Encoding a larger object takes roughly a millisecond on my machine.

Building the Library and the Framework Challenges

I structured the project as a pnpm monorepo. TypeScript dominates the codebase. Core logic lives in one package. Thin adapters cover Next.js, React Router, and Remix. Rollup manages the build. Nothing overly complicated.
Next.js App Router created the biggest difficulties. The way searchParams moves between server and client components caused repeated issues. I added a small header workaround to carry data through on the server side. Hydration stayed intact. Remix and React Router presented fewer obstacles, yet I still needed to handle history modes, push versus replace, and debounce settings so the URL stayed calm during typing.

Here is a real section from the Next.js 15 demo that runs live at state-in-url.dev

'use client'
import { useUrlState } from 'state-in-url/next';
import { formState } from './formState';

function Form() {
   const { urlState, setUrl, setState } = useUrlState(formState, { searchParams });
    return (
     <input
       value={urlState.name}
       onChange={(e) => setState(curr => ({ …curr, name: e.target.value }))}
       onBlur={() => setUrl()} // update URL on blur for smoother typing
     />
     {/* tags, dates, checkboxes - all typed correctly */}
   );
}

The code stays simple. It is just state that happens to live in the URL.

Testing was hard but important

I needed the library to feel reliable across frameworks and browsers. Real example apps for Next.js 14+, React Router v6+, and Remix live in the repo. Vitest covers the encoder and decoder basics. More real world tests cases covered with Playwright running full end-to-end tests in Chrome, Firefox, and Safari.

A fix in one place often broke something elsewhere. The commit message "Tests finally passing on Next.js 15" appeared more times than I care to count. It took quite few attempts adjusting Playwright configurations and the CI matrix.
GitHub Actions now runs linting, building, unit tests, and the complete browser suite on every push and PR. Semantic-release automates version bumps, changelog updates, GitHub releases, and npm publishing. Husky keeps commits tidy. Once the pipeline ran smoothly, maintaining the library stopped feeling like a burden.

Launching

I published to npm. The README received every recipe I could gather - debounced updates, resetting to defaults, multiple independent state objects on one page. I linked the live demo and waited.
The first stars arrived and felt surprisingly satisfying. Issues opened, mostly kind ones. Solid CI let me ship fixes quickly. I wrote the honest limits in a separate Limits.md file. URLs hold only so much - around 12 KB stays practical. Readers seemed to value the directness.

Lessons

Making the API match useState exactly shaped every other decision and made the library pleasant to use.
That single object for shape and defaults removed a lot of complexity.
Testing inside real frameworks felt painful yet essential - skipping it would have limited adoption.
Automating releases and chores with semantic-release and GitHub Actions turned maintenance into something manageable.
Keeping the bundle tiny happened on purpose. I watched the size and avoided dependencies deliberately. Would I change anything today? I might add Svelte or Astro support earlier. Hash routing could be interesting. The roadmap still has room to grow.

If this sound interesting give it a try

pnpm add state-in-url

The demo lives at state-in-url.dev. The repository sits here. Star it if the approach fits your work.

I would enjoy hearing about the URL-state problems you encounter. Leave a comment. Open an issue. Send a pull request. Sharing the process publicly became one of the most rewarding aspects.
Happy coding, MIT license, of course. Build something useful with it.

New portfolio website

Alex — Mon, 15 Sep 2025 15:24:22 +0000

Tried few new things this time.

Created an initial design with V0, had to refactor a lot, and change many details.

Chose an Astro framework for a minimal footprint on bundle size, and the best performance.

It's quite simple, but hopefully worth it. Will appreciate any feedback.

Portfolio link

React rendering quiz

Alex — Thu, 08 May 2025 09:55:24 +0000

A simple quiz to illustrate how React rendering works.

import React from "react";

export default Parent;

function Parent() {
  console.log("1");
  React.useEffect(() => {
    console.log("2");
  }, []);

  return (
    <>
      Parent component
      <br />
      <Child />
    </>
  );
}

function Child() {
  console.log("3");

  React.useEffect(() => {
    console.log("4");
  }, []);

  return <span>Child component</span>;
}

Try to guess what will be printed to console.

Answer

Some explanation:
⇾ First Parent is parsed and rendered, without useEffect,
⇾ after that Child, when there is no more nested components is turn of async hooks
⇾ React will run useEffect from children to parents.

Few more logs, probably related to dev mode.

Breakpoints variables with pure CSS

Alex — Thu, 01 May 2025 10:28:18 +0000

In CSS can use variables most of the time.

:root {
  --color-main: red;
}

But, can't use variables in @media queries.

@media (min-width: var(--br-md) {
/* will never work */
}

Unexpected solution is to use @container queries:

:root {
  --is-tablet: true;

  @media (min-width: 1200px) {
    --is-tablet: false;
  }
}

...

@container style(--is-tablet: false) {
  .content {
    grid-template-areas:
      'header aside'
      'feed   aside';
    grid-template-rows: minmax(7.16rem, 17.6rem) minmax(7.16rem, max-content);
    grid-template-columns: var(--feed-columns);
  }
}

Only downside is Firefox lacks support of it, but it doesn't do so well on many things.

Next.js usage

In Next.js can use postcss-custom-media plugin to achieve same outcome, for all browsers and with css modules.

How it looks like

@custom-media --is-desktop (min-width: 1200px);

...
@media (--is-desktop) {
  .content {
    grid-template-areas:
      'header aside'
      'feed   aside';
    grid-template-rows: minmax(7.16rem, 17.6rem) minmax(7.16rem, max-content);
    grid-template-columns: var(--feed-columns);
    gap: 1.75rem;
    width: 100%;
  }
}

Setup

Official docs

Install all dependencies:
npm install --save-dev postcss autoprefixer postcss-flexbugs-fixes @csstools/postcss-global-data postcss-custom-media postcss-preset-env
Add PostCSS config to package.json:

  "postcss": {
    "plugins": [
      "postcss-flexbugs-fixes",
      [
        "@csstools/postcss-global-data",
        {
          "files": [
            // need to use file with global variables here
            "core/styles/vars.css"
          ]
        }
      ],
      "postcss-custom-media",
      [
        "postcss-preset-env",
        {
          "autoprefixer": {
            "flexbox": "no-2009"
          },
          "stage": 3,
          "features": {
            "custom-properties": false
          }
        }
      ]
    ]
  }

Minification bugs

Alex — Fri, 04 Apr 2025 11:37:21 +0000

Today I learned that minification in JS is a double-edged sword.

It was a weird bug, took me quite some time to figure out that problem in minification.
Stopped using terser for the same reasons.

Next.js at refactor or extinct situation.

Alex — Fri, 13 Dec 2024 08:21:03 +0000

Next.js become a hype of the day (or year), but it's slowly suffocating under the weight of technical debt.

There are many big enough pain points with Next.js:

Slow and painful dev mode, if you changed something and need to check more than 1 route, you need to wait till route compiled. Next.js server also uses few gigabytes of RAM. Turbopack complaining about perfectly working TS code, and struggle to understand :global in CSS modules, still not production ready.
Whole workflow is intended to be used mostly with server components, but in real world applications big chunks of applications use client side JS, because it's way faster and more responsive.
Routing is a mess, pages router was good enough, but App Router it's just a wrapper around it, that lead to more bugs and complexity.
Vercel service is good, but if popularity of your project going parabolic, costs will follow - 96k bill

Just stumbled upon a bug when useParams hook periodically returning dead wrong values.

Searched for existing issues, didn't find any, tried to open issue on their GitHub, can't do than without providing reproducible example. Repository is private, I can't share all of it. And I can't pinpoint the exact condition for a bug to appear in a big enough codebase.

Similar situation was with Cypress testing framework. For years people opened issues about flaky tests and memory leaks, all of them were closed, because can't properly reproduce them. Easy to make something works in a TODO app, real challenge is a big and complex application. Usually, people work under NDA and can't just share the whole repository.
After some time Playwright came and Cypress isn't relevant any more.

Let's see approximate quality ratio, by calculating stars to bugs for Cypress.

47600 stars / 14600 bugs = 34 quality

Cypress's successor - Playwright

67_700 stars / 692 issue = 97 quality

I'm aware that many bugs issues it's just misunderstanding or duplicates, still, if something confusing in a documentation/example, it is a con of software.

Let's see about Next.js

128_000 stars / 3000 bugs = 42 quality

Let's see React.js repo for context

230_000 stars / 754 bugs = 305 quality

And Remix.js repo (SSR framework from react-router team)

30_300 stars / 295 bugs = 102 quality

All of this just my opinions, but it's backed by years of experience with different frameworks/libraries and observations.

Beyond console.log

Alex — Sun, 24 Nov 2024 09:49:53 +0000

intro

As much as I hope that things will always work from first try, better to be prepared to debug it. console.log remains the main tool to do it, because it is the simplest and fastest.

Few console methods are known to everybody, log, warn and error.

Going deeper

There are more tricks to it.

`count`

For example, if you need to count how many times component re-render can use console.count, e.g. console.count('comp1')

`group` and `groupCollapsed`

Can log some info in a collapsed group with console.groupCollapsed, great in case of many error messages, when they printed collapsed it's less distracting, but Node.js/Sentry probably will print all expanded.

After click

styling

Can use some CSS

`dir`

Can log properties of an object with console.dir

objects

Can log few objects with curly braces like console.log({ obj1, obj2 }), instead of console.log('Ojb1', obj1)

`assert`

Can assert things with console.assert

`time`

Can measure how long some operation takes with console.time

`trace`

Print a stack trace with console.trace()

`clear`

Clear things up with console.clear()

Check out great old post - https://dev.to/lissy93/fun-with-consolelog-3i59

First really useful AI tool - AI code review

Alex — Thu, 14 Nov 2024 20:42:30 +0000

Finally, I found at least 1 really useful AI service.

The service

It's called CodeRabbit, the idea behind it is pretty simple, AI review code changes and give you recommendations how to fix it with explanation.

AI is working as pattern recognition, so, it's perfectly suitable for recognizing antipatterns in pull requests.

How it looks like

After PR created, GitHub action run and analyze changes. It's post summary like this:

The second comment contains recommendations:

Conclusion

This service already found few minor mistakes that I missed. Definitely worth trying.

Reviewing PRs is a very tedious task, AI can actually help with it.

Of course there are probably 3 useful comments out of 10, but it is very similar with human reviewers, e.g. they're either nitpicking the every line or blindly approve huge PR.

Treat such comments as possibly useful recommendation, not like obligation to fix everything.

Price

Currently, you can use it for free with basic functionality, and 12$/month for Pro version.
Probably, this promotion-like pricing will change in the future, but again, worth giving it a try.

Solving slow compilation in dev mode for Next.js

Alex — Fri, 08 Nov 2024 12:04:05 +0000

Noticed that Next.js dev server is really slow, annoying that it can't precompile pages in the background.
There is a discussion about it.

Ways to make it faster

Turbopack

Can use turbopack, can run it with next dev --turbo, downsides that if you use some fine tweaks for Webpack, not everything works correctly with turbopack (at least for v14).

Upgrade to Next.js v15

v15 is faster by default, some common issues were solved. There is a codemod that will do most of the things for you in a few seconds.
Still, requires some effort.

Config tweaks

There is onDemandEntries option for next.config.js, can use it to force dev server to store more compiled pages in memory, so you will see fewer compiling /page ... lines.
For example:

const nextConfig = {
  onDemandEntries: {
    // period (in ms) where the server will keep pages in the buffer
    maxInactiveAge: 15 * 60 * 1000, // 15 minutes
    // number of pages that should be kept simultaneously without being disposed
    pagesBufferLength: 4,
  },

Tnx for reading.

Dark side of Next.js - App Router

Alex — Wed, 06 Nov 2024 19:57:49 +0000

Today, I want to share the disappointing issue with Next.js - App router.

About SSR

I assume that you're aware of what SSR is and vaguely understand how it works.
E.g. server return HTML page with markup, while JS and CSS bundles downloading, user see the page instantly and parsing JS code taking some time.

The `_rsc` problem

Every time you switch route in Next.js, it's requesting some meta info from server first, you can see such requests as {smt}_rsc, stand for _ReactServerComponent as I can guess.

Server responds with something like this

Problem that Next.js router make those requests even if you need to update searchParams, e.g. /url?param=value, it isn't a new page, all purely client side, but there is still a _rsc request.

Another example, when have list with cards, every card has an edit button with Next/Link component, and separate edit page like /card/{some_id}/edit.
Next.js trying to optimize things and prefetching those _rsc requests ahead of time. In result, there will be a request for every card, but user possibly won't ever click an edit button.

Even if you have very fast server and internet connection, network requests making UI slower, and put more stress on a server.

While SSR is great for an initial page load, navigation after app loaded happens way more often.

Discussions

There are few discussions about this problem:

How to solve it

Switching to something like Remix will be too hard for existing project.

Can use plain old window.history interface with pushState/replaceState instead of App router, when you sure it purely client side.

For queryParams/searchParams can use a library to simplify those things - state-in-url , it's using history by default and has an option to use App router. Also, it's way simpler than NUQS, parsing with proper type just work out of the box.

Tnx for reading, consider giving it a like and maybe share.

Surprising benefit of GraphQL for long-term maintainability

Alex — Wed, 30 Oct 2024 17:03:18 +0000

When it comes to Frontend-Backend communication, there are few options:

REST
OpenAPI
GraphQL.

At the first glance, GraphQL seems like overkill that slowing down the whole team.

But as the project grows, complexity grows as well. Eventually you will come to a situation when seemingly simple change can break something in the other part of the application, something you couldn't possibly think of.

The obvious solution to it is tests, with Cypress or Playwright. In unit tests, many of the browser APIs are unavailable or behave differently, and most of the bugs hide in how a dozen of simple components glued together.

With REST there is no schema to describe API endpoints, OpenAPI has the schema, but validating against it is very tricky. Only GraphQL option left.

There are 2 ways to frontend testing:

Record API requests/responses and replay them during tests.
Set up the whole backend and populate proper test data for every test case.

Using live backend for tests requires huge amount of effort, need to populate data before test, run the test and clean up at the end. It will take too much time to go this way.

So, we end up with recording API communications. But what happen if API definition changes?

And here GraphQL really shines, at least Apollo GraphQL.
Any inconsistency on the schema between backend and frontend will fail the test.
It's mean that any code change that affect API contract will be caught in time.

So, any complex enough application will be way more maintainable with GraphQL.

Tnx for reading, share your thoughts in comments, like and subscribe, you know the drill.

Why I don't specify pronouns

Alex — Mon, 30 Sep 2024 09:48:42 +0000

Can see preferred pronouns on some GitHub profiles.

I want to discuss why I don't do it, why I don't think anybody should, and why it isn't a good thing.

A recent example - ‘Concord’ Developer Demanded Co-Workers Refer To Her As “Professor,” Pushed “Extreme Politics,” And Demanded Her Unvaccinated Colleagues Be Fired. This come to light because of epic failure of Concord game.

Arguments for

Respecting rules and agreements of group/society/company is a nice social treat. That it.

Arguments against

Need to remember pronouns for everybody, add it to struggle to remember names of people in a company. Inconvenient.
Some of the pronouns contradict English grammar and common sense. It could be a big deal for neurodivergent people, so it's exclude them.
It's impose a set of ideology on everybody, how you will feel if somebody will demand to remove all globes from everywhere because some believe that earth is flat? Or putting a flat globe near every spherical one?
Person is falling for every trend and hype, better to use common sense approach. There are countless hypes in SE industry, css-in-js, microservices, and more. All of them has downsides and price to pay.

5. And most interesting topic, follow me.

There are some psychological treats that undesirable in a work place, even a red flag if we're talking about management. Narcissism is one of them.

Looking on definition of narcissism

selfishness, involving a sense of entitlement, a lack of empathy, and a need for admiration, as characterizing a personality type

And some description

Believe they are superior to others and can only spend time with or be understood by equally special people. Be critical of and look down on people they feel are not important. Expect special favors and expect other people to do what they want without questioning them. Take advantage of others to get what they want.

So why this is a bad thing for a company?

There tends to be a higher level of stress with people who work with or interact with a narcissist. While there are a variety of reasons for this to be the case, an important one is the relationship between narcissism and aggression. Aggression is believed to moderate the relationship between narcissism and counterproductive work behaviors. According to Penney and Spector, narcissism is positively related to counterproductive workplace behaviors, such as interpersonal aggression, sabotaging the work of others, finding excuses to waste other peoples' time and resources, and spreading rumors

There are discussions about this,New York Times article

Some tactics used by narcissists:

Gaslighting
Playing the Victim
Projection
Hoovering
Smear Campaign
Revenge Seeking

Hope that you google this topic and think about it. All of it seems like some modern politics is justification of narcissism.

What about hiring?

Quote from wiki:

Narcissists typically perform well at job interviews; they receive more favorable hiring ratings from interviewers than individuals who are not narcissists. Typically, because they can make favorable first impressions, though that may not translate to better job performance once hired.

What you can do if you work with one?

Playing along

There is temptation to just appease such person, but it will make it worse in a long term. Such people (and other not so pleasant ones) desire power over others, if you go along with their games 1 time, they will expect it again tomorrow.

Fighting

Fighting and conflict isn't any better, narcissists develop many defense mechanisms to avoid dealing with their own shortcomings, they have ready to use proved tactics to win in such situation.
They will use manipulations and tricks, often dirty ones, playing a victim, lying, rumors and false accusation are expected.

"Solution"

Maintain your boundaries, preserve your right to chose your own beliefs, don't start confrontation intentionally, be professional and careful. I recommend to search for some YouTube videos on this topic, like "Surviving Narcissism".

What is your experience and opinion about this? Post it in comments.
Also, like and share this if you think it's interesting.

Forem: Alex

How I Built state-in-url: My Journey Turning the URL Bar into Real React State

The Problem

The solution

Building the Library and the Framework Challenges

Testing was hard but important

Launching

Lessons

New portfolio website

React rendering quiz

Breakpoints variables with pure CSS

Next.js usage

Setup

Minification bugs

Next.js at refactor or extinct situation.

Beyond console.log

intro

Going deeper

count

group and groupCollapsed

styling

dir

objects

assert

time

trace

clear

Related

First really useful AI tool - AI code review

The service

How it looks like

Conclusion

Price

Solving slow compilation in dev mode for Next.js

Ways to make it faster

Turbopack

Upgrade to Next.js v15

Config tweaks

Dark side of Next.js - App Router

About SSR

The _rsc problem

Discussions

How to solve it

Surprising benefit of GraphQL for long-term maintainability

Why I don't specify pronouns

Arguments for

Arguments against

5. And most interesting topic, follow me.

Some tactics used by narcissists:

What about hiring?

What you can do if you work with one?

Playing along

Fighting

"Solution"

`count`

`group` and `groupCollapsed`

`dir`

`assert`

`time`

`trace`

`clear`

The `_rsc` problem