superlucky84

A bit more context on why I built this:

I like MPA simplicity, but I also wanted progressive in-page updates without turning everything into a SPA with client state, router logic, and hydration complexity.

So this project is basically me asking:

Can the server remain the source of truth for UI state, while the client only handles DOM projection for named slots?

I’m not claiming this replaces React/Next/etc. I’m trying to see whether this model is useful for a narrower class of apps: - streaming interfaces - server-driven workflows - multi-step forms - dashboards - agent / assistant-style UIs

Very interested in where people think this idea is promising vs fundamentally awkward.

Built this after repeatedly losing context between multiple AI agents working on the same repo and branch.

I wanted something boring, explicit, and repeatable — no hidden memory or session magic. Curious how others here handle AI agent handoffs or shared context today.

fp-pack is also intentionally scoped for everyday frontend developers.

It tries to borrow function composition and declarative structure without requiring familiarity with full FP abstractions like monads or effect systems.

One more practical point is that a full monad doesn’t fit very naturally into a pipe-first interface.

Once you commit to a real monad, you need map/flatMap, lifting, unwrapping, and rules about staying inside the context across the whole pipeline. At that point, the pipe abstraction stops being the primary mental model — the monad does.

SideEffect deliberately avoids that. It keeps the pipe interface intact and only adds a single, explicit signal: “stop here”. That’s why it’s less powerful than a monad, but also much simpler to integrate into existing pipe-based code.

I understand the concern.

The intent isn’t to add more side effects to an already side-effectful language. It’s closer to the opposite: trying not to handle side effects all over the place, but to surface them as part of a single, explicit flow.

This is less about adding something like Option to a language without nulls, and more about making control-flow boundaries visible in a multi-paradigm language where effects already exist.

It’s not an attempt to pretend the language is pure, just a small step toward more declarative discipline.

I really relate to that.

There’s often a gap between what feels conceptually clean and what teams are actually willing to carry cognitively. Rx in particular tends to exceed that budget pretty quickly.

That’s why fp-pack is intentionally narrow — it’s closer to making a few control-flow cases explicit in pipe-first code than introducing a broad new abstraction.

Good question.

Early termination is the most common use case, but it’s not the only thing SideEffect represents. The name is intentionally a bit broader — it’s meant to model “effects where normal composition should stop”.

In practice, that includes things like validation failures, logging or notifications at pipeline boundaries, and error reporting or metrics. That said, the scope is deliberately conservative.

SideEffect isn’t meant to be a general-purpose effect system. If it were, it would quickly turn into something very close to a monad or effect framework, which I’m intentionally avoiding.

That’s a fair point — it can definitely become a footgun if you’re not careful.

This happens because `runPipeResult` defaults its generic parameter to `R = any`. When type safety matters, the intended solution is to use `pipeSideEffectStrict`, which preserves all possible SideEffect result types as a precise union throughout the pipeline.

The default version prioritizes ergonomics and simplicity, while the strict version prioritizes type safety.

Also, fp-pack is still in an early stage, so the usability and API choices haven’t been fully validated yet. That’s why feedback like this is especially helpful in shaping the direction of the library.

That’s a fair point, and I agree.

The SideEffect pattern is intentionally explicit, so without fp-pack context it can look unfamiliar at first. The trade-off is making early exits visible in the code, rather than hiding them in conditionals or exceptions.

In practice, most code stays in plain pipe/pipeAsync. SideEffect is meant for a small number of boundary cases only.

And I agree — better language-level syntax for this kind of pattern would make it much easier to adopt.

It’s definitely monad-adjacent.

The main difference is that SideEffect isn’t a compositional context — there’s no bind/flatMap, and composition intentionally stops once it appears. It’s meant as an explicit early-exit signal in pipe-first code, not a general computation container.

One thing I’d especially like feedback on is the SideEffect approach.

It’s intentionally not a monad, and I’m curious how others feel about this trade-off compared to Option/Either in real-world TypeScript codebases.

The default mode is that values reactively respond, and it also provides a mode that allows for easy Flux-like architecture.

StateRef is a state management library focused on data immutability.

It combines proxies and the functional programming lens pattern to efficiently and safely access and modify deeply structured data.

It provides more direct and fine-grained state management compared to other types of state management libraries.

It is also designed for easy integration with other UI libraries. We provide code snippets for connecting with React, Preact, Vue, Svelte, Solid, and Lithent , and users can also create their own connection snippets.

looks good

Look so good