About Rxova

Jonatan Kruszewski

Senior Frontend Engineer

Senior Frontend Engineer focused on React architecture, reusable developer infrastructure, and tools for complex user interfaces. Rxova is where I build focused open-source libraries with stable APIs, strong TypeScript support, thorough testing, and documentation that answers the question you actually arrived with.

Day to day that means React architecture at application scale: state that survives a refactor, component APIs a team can use without reading their implementation, and the developer-facing infrastructure — types, tests, documentation, release pipelines — that decides whether any of it is still usable a year later. Rxova is that same work, done in public, at a scope small enough to actually finish.

Why Rxova exists

Most of these libraries began as the same code written for the third time. A currency input that keeps the caret where the user left it. An OTP field that does the right thing with a pasted code. A way to describe a multi-step, branching flow that does not decay into a pile of booleans and effects. Each had been solved before — privately, inside a product repository, in a form that could not travel to the next project.

Rxova is where that work stops being private. It is an umbrella, not a company: a shared set of standards for what counts as finished, one design system across the docs, and a single place to look for any of it. The projects underneath stay independent — separate repositories, separate releases, separate decisions to adopt.

What the projects share

Journey, react-inputs, use-everywhere solve unrelated problems. These four rules are what make them one ecosystem, and they are stated so you can check the code against them.

1. Focused APIs, not frameworks

   Each library solves one problem and stops there. No plugin system, no configuration to learn before the first useful line.

   Journey models flow graphs — it does not route, fetch, or render for you. react-inputs ships inputs, not a design system. A small surface is one you can hold in your head, and it is the only kind that can credibly promise to stay stable, because most of the work of keeping an API still is saying no to what does not belong in it.

2. TypeScript-first, with explicit framework boundaries

   Types are part of the public API, not generated as an afterthought — and the framework-agnostic core always ships apart from its React bindings.

   That boundary is a package, not a convention: @rxova/journey-core and @rxova/journey-react are separate installs, and so are @use-everywhere/core and use-everywhere. The core runs in a worker, a test, or a non-React app; the bindings stay thin enough to read in one sitting. Autocomplete is expected to answer most usage questions before the docs do.

3. Accessible, tested, production-oriented behaviour

   Keyboard handling, ARIA, focus, and locale are part of the component — not an issue filed after launch.

   These libraries exist mostly because of the details that get skipped: the caret jumping to the end of a currency field mid-typing, a paste into the second OTP slot that should fill all six, a rating control that cannot be reached with a keyboard. Those cases are what the test suites are about, and they are the reason a component that looks trivial is worth taking as a dependency.

4. Independent packages, adopted one at a time

   Nothing here requires anything else here. Take one package, keep the rest of your stack exactly as it is.

   There is no meta-package and no shared runtime you are opted into by installing one library. Dependency lists stay short and reviewable on purpose, so that adopting a package is a decision about that package alone — and so that dropping it later is a single uninstall rather than an unpicking.

Is it actively maintained?

Yes — and the honest way to check is not a badge on this page. Updates records every release, pipeline change and decision as it happens, and each repository's commit history is public. If a project ever goes quiet, those will show it long before any claim here would.

What one maintainer can commit to: issues get read, security reports come first, and a released API does not change under you without a major version and a migration note. What it would be dishonest to promise: same-day fixes, or a roadmap driven by feature votes. Knowing which of those you are getting is the point of saying it is one person's work.

Contributing

Contributions are welcome, and the most useful ones are smaller than people expect:

• A bug report with a minimal reproduction. It is worth more than a patch — most of the fixing time is spent getting the failure to happen on demand.
• A focused pull request. One behaviour, with the test that fails without it. Large refactors are best raised as an issue first, so neither of us spends a weekend on a direction the other would not take.
• A documentation fix. If something was unclear enough to cost you an hour, saying so is a contribution even without the patch.

Each library is developed in its own repository under github.com/rxova, so issues and pull requests belong there rather than here:

• Journey Declarative journey graphs for non-linear UI flows.
• react-inputs The tricky React inputs, done right.
• use-everywhere State and messages that exist in every tab, window, and worker.

For anything that does not belong in public — a security report, or a question you would rather not file — rxova@proton.me reaches me directly. Longer write-ups on how these are built go on the blog.