Forem: Brian Love

Agentic Memory and What It Means for Web Apps

Brian Love — Wed, 18 Mar 2026 23:02:39 +0000

Memory is becoming one of the most important design surfaces in agentic software.

Not because models suddenly became databases.
And not because storing more transcripts is the same thing as making a system smarter.

It matters because memory changes what kind of software we are building.

A stateless LLM can answer.
A system with agentic memory can improve.

That is a different class of product.

For me, the core idea is simple:

memory turns LLMs from stateless responders into stateful systems
memory is a form of non-parametric learning
the hard problem is no longer storing more context
the hard problem is deciding what should be remembered, when, and in what form

If you are building fullstack agentic web applications, this is the shift to pay attention to.

tl;dr

Agentic memory is not just retrieval. It is an agent capability to store, retrieve, update, summarize, and delete knowledge over time.
This gives us a practical form of continual learning without fine-tuning model weights.
For web apps, memory changes architecture, not just prompting. It affects UX, data modeling, evaluation, governance, and trust.
The right production model is usually typed memory, selective retrieval, background consolidation, and immutable raw history behind derived memory.
Memory is becoming an agent policy surface. That means memory quality will matter as much as model quality.

Angular Agent Framework

Check out CachePlane's Angular Agent Framework at cacheplane.ai for building agentic fullstack Angular applications using LangChain.

Why memory changes everything

Most LLM applications started as stateless request-response systems.

That was fine for summarization, classification, and one-shot chat.
It is not enough for software that is supposed to improve over time.

As soon as you want an agent to:

remember user preferences
reuse successful workflows
avoid repeated failures
carry state across sessions
personalize behavior without retraining

you need memory.

And not memory in the casual sense of "we saved the conversation somewhere."

You need a system where the agent can actively manage what it knows.

That is what makes the memory agentic.

What agentic memory actually is

Agentic memory is a system where an agent can decide to:

store something
retrieve something
update something
summarize something
delete something

That last point matters.
If the system can only append, it does not really have memory discipline.
It has a log.

This is why I think the right framing is:

Memory is not storage. It is a control surface for reasoning.

That is the real shift.

Agentic memory is like cramming for a test

One of the more important ideas here is that memory gives us a form of continual learning without changing model weights.

The model does not need to be fine-tuned every time it learns something useful.
It can improve by pulling the right memories into context at inference time.

That is why I think of memory as test-time learning.

Different systems approach it differently, but the common idea is the same:
the agent gets better because it can reuse abstractions learned from prior experience.

That is a much more practical path for product teams than constant retraining.

The three memory types that matter

I think it is useful to separate memory into three buckets:

Semantic memory
Episodic memory
Procedural memory

1. Semantic memory

Semantic memory is facts, preferences, constraints, and stable knowledge.

Examples:

preferred output format
user role
account rules
domain terminology
known business constraints

This is the memory type that drives correctness and personalization.

2. Episodic memory

Episodic memory is past experiences.

Examples:

a successful prior resolution for a similar support issue
a failed workflow and the correction that fixed it
a previous user interaction pattern

This is the memory type that helps reasoning by analogy.
It is how agents get a practical form of "I have seen something like this before."

3. Procedural memory

Procedural memory is behavior.

Examples:

preferred prompts
tool-use patterns
routing rules
safety policies
execution instructions

This is the memory type that improves consistency.

I think this separation matters because different memory types want different storage, retrieval, and evaluation strategies.

If you flatten them all into one vector store, you are usually making retrieval worse.

What this means for web apps

This is the part I care about most.

Agentic memory is not just an infra feature for backend agents.
It changes how web apps should be designed.

A web app with agentic memory is not just rendering model output.
It is participating in a learning loop.

The frontend becomes the place where memory is created, corrected, and validated.

That has a few practical implications.

1. Web apps become memory surfaces

The frontend sees things the model and backend often do not:

what the user accepted
what they edited
what they rejected
how long they hesitated
where they retried
when they abandoned

Those are memory candidates.

Not all of them should be stored.
But the web app is where those signals become visible.

2. Personalization becomes a first-class product system

Personalization used to mean feature flags, settings, and saved preferences.

Now it also means memory.

The agent should be able to remember:

how a person likes information presented
what defaults they repeatedly choose
what kinds of actions they permit or avoid
what vocabulary is normal in their context

That is a better product experience.
It is also a new governance problem.

3. Multi-session coherence becomes a UX expectation

Once users see an agent remember important context, they start expecting continuity.

That means the web app needs to help answer questions like:

what should persist across sessions?
what should expire?
what should be editable by the user?
what should be visible as remembered state?

This is why memory is also a UX problem, not just a systems problem.

4. Context engineering becomes product infrastructure

I think "context engineering" is one of the most useful phrases in this space.

The problem is no longer just fitting more tokens into a prompt.
The problem is selecting the right abstractions.

Bad memory systems create:

context poisoning
distraction
token waste
conflicting guidance
brittle personalization

Good memory systems do the opposite:

selective retrieval
summarization
distillation
isolation by scope
time-aware filtering

This is why I would argue:

The problem is no longer remembering more. It is remembering the right abstractions.

Reflection is where memory becomes learning

One of the most important loops in agent systems is:

act
observe
critique
store
reuse

That is reflection.

In practice, a lot of the gains in agent quality come from this loop.
The agent does something, observes success or failure, stores the useful lesson, and applies it later.

This is why grounded reflection matters so much.
If the critique comes from real environment feedback, user behavior, or verifiable outcomes, the memory is much more useful than a purely self-generated summary.

This is also why the web app matters so much.
It is often the best place to observe the real outcome.

The architecture I would actually ship

If I were building agentic memory into a web app today, I would not start with one giant memory store.

I would use a layered design:

Short-term thread memory
Long-term typed memory
Immutable raw history
Background consolidation

Short-term thread memory

This is the active working set for the current task or session.

Use it for:

recent messages
in-progress tool state
temporary planning context
current UI state

This is hot memory.
Fast in, fast out.

Long-term typed memory

This is where semantic, episodic, and procedural memories live separately.

Use it for:

user preferences
reusable examples
learned task heuristics
stable operating policies

This is where I want stronger structure and stronger retrieval rules.

Immutable raw history

Never trust repeated summarization as your only source of truth.

Summaries drift.
Compression loses nuance.
Derived memory can get subtly wrong over time.

So I want a raw, immutable log behind the optimized memory layer.

That gives me:

auditability
rollback
better debugging
safer reprocessing

Background consolidation

Not every memory write should happen synchronously in the request path.

Some should.
Others should be consolidated later.

That is the hot + cold model:

synchronous writes for critical immediate context
asynchronous consolidation for summarization, distillation, and indexing

That is usually the right tradeoff between latency and memory quality.

Patterns I like

There are a few patterns here that I think are especially practical.

Hot + cold memory

Write immediately when the task needs it.
Consolidate later when quality matters more than latency.

Distilled memory

Do not store raw transcripts as the primary memory object if what you really need is a reusable abstraction.

Store:

the lesson
the source
the timestamp
the confidence
the scope

That is much more useful than dumping an entire conversation into retrieval.

Immutable + derived memory

I trust systems more when they keep both:

immutable raw events
derived summaries and optimized memories

That is how you keep memory systems from becoming opaque.

Memory graphs

Similarity search is useful, but it is not enough.

Some memories are connected by:

causality
sequence
dependency
contradiction

Graph-shaped memory is much better at expressing that than naive top-k vector retrieval.

I expect more systems to move in this direction.

The production risks are real

Memory makes systems better.
It also makes them more dangerous.

At least four risks matter immediately.

1. Retrieval quality

Just because something is semantically similar does not mean it is operationally relevant.

Memory retrieval often misses:

causal relevance
implicit constraints
temporal change
contradictory updates

This is why memory quality is usually more important than memory volume.

2. Memory drift

If you repeatedly summarize summaries, you eventually distort the original meaning.

That is why derived memory needs provenance and raw backing data.

3. Security

Memory injection is a real design concern.

If an attacker can poison memory, they can shape future agent behavior.

This means memory systems need:

validation
trust boundaries
scoped access
deletion paths
source attribution

4. Evaluation

A memory system can look impressive in a demo and still fail long-horizon tasks in production.

We still need better evaluation for:

multi-session behavior
long-horizon execution
memory usefulness over time
robustness to stale or conflicting memories

Memory governance is now part of application architecture

This is the part I think teams will underestimate.

As soon as memory affects behavior, governance matters.

You need clear rules for:

what gets stored
who can access it
how it decays
how it is corrected
how it is deleted
how it is explained to the user

This is true for enterprise software.
It is even more true for consumer software.

The best systems will not just remember well.
They will remember responsibly.

My practical recommendations

If you are building agentic memory into a web app now, this is the sequence I would use:

Separate semantic, episodic, and procedural memory.
Keep immutable raw history behind derived memory.
Prefer distilled memory objects over raw transcript retrieval.
Add time, source, scope, and version to every stored memory.
Use synchronous writes sparingly and background consolidation aggressively.
Tune retrieval strategy by memory type instead of using one global approach.
Evaluate on multi-session and long-horizon tasks, not only single-turn quality.

That is the difference between "we added memory" and "we built a memory system."

Closing

Agentic memory changes the role of the model.
It also changes the role of the web app.

The web app is no longer just a place where model output gets rendered.
It is where memory is shaped, corrected, surfaced, and governed.

That is why I think memory is going to become foundational to intelligent software.

Not because remembering more is inherently better.
But because the right memory architecture lets software learn without pretending every improvement requires retraining.

Memory is becoming policy.
And policy is becoming product behavior.

That is what makes this interesting.

Google A2UI: Fixed Schemas, Dynamic Schemas, and a Safe Fallback Strategy

Brian Love — Wed, 18 Mar 2026 23:02:39 +0000

Google's A2UI is one of the more interesting protocol ideas in agentic UI right now.

Not because it lets a model generate arbitrary frontend code.
That would be a fast way to move chaos across a trust boundary.

It is interesting because it does the opposite.

A2UI gives the agent a declarative way to describe UI while keeping rendering inside a trusted client-owned component system.

That is the part that matters.
Especially if you are building a real product instead of a demo.

The practical question is not whether A2UI is good.
The practical question is how to use it without turning your UI contract into a probabilistic event.

For me, that comes down to one decision:

Fixed schema
Dynamic schema

My recommendation is simple:

Use fixed schemas by default.
Use dynamic schema overlays for the long tail.
Validate everything.
Retry a few times.
Fall back deterministically.

tl;dr

A2UI is a protocol for agent-driven interfaces where the client owns rendering and the model emits declarative UI messages.
A2UI v0.9 is more model-friendly than earlier versions because it is flatter, more prompt-friendly, and easier to validate.
Most teams should start with fixed schemas because they are easier to test, easier to operate, and easier to trust.
Dynamic schemas are useful, but only when they stay grounded in renderer-approved catalogs.
The right production posture is fixed by default, dynamic overlays for the long tail, and deterministic fallback when validation fails.

The Angular Fullstack Agentic Frameowork

Be sure to check out the Angular Agent Framework for building fullstack agentic applications using Angular. A2UI support will be landing soon!

Fullstack architecture sketch

Before getting into fixed versus dynamic schema, this is the deployment shape I would use:

Web Client
  - trusted A2UI renderer
  - advertises supported catalogs
  - may advertise inline catalogs
  - sends actions and data model updates

API / Agent Backend
  - receives client capabilities
  - selects fixed vs dynamic policy
  - builds prompt from selected catalog
  - runs schema repair loop when dynamic
  - validates final payloads
  - streams safe A2UI messages to client

Observability
  - schema validation failures
  - payload validation failures
  - fallback frequency
  - per-intent success rate

Why A2UI matters

A2UI matters because it gives us a cleaner split between model behavior and frontend control.

The model decides what interface should appear.
The client decides how that interface is rendered.

That is a much better contract than shipping arbitrary frontend code across the wire and pretending the security story will work itself out.

Why v0.9 is the interesting version

One caveat up front:
A2UI v0.9 is still a draft, while v0.8 is the stable production release.

So this is not a "ship and forget" protocol.
You should pin versions and test contracts carefully.

But v0.9 is still the version I would watch, because it is the version that feels much more usable for agent systems.

The notable shifts are:

a prompt-first design
createSurface replacing beginRendering
a flat component model with a component discriminator
more standardized updateDataModel
swappable catalogs instead of a single hardwired shape

That makes the protocol easier to prompt, easier to generate, and easier to validate.
That is the real win.

A quick note on what "schema" means here

When people say "fixed schema" or "dynamic schema" in the context of A2UI, they usually mean something looser than a single JSON Schema file.

In practice, the protocol is made up of separate artifacts:

a server-to-client envelope
shared common types
one or more catalogs that define renderable components

So the real decision is usually this:

do you give the model a fixed catalog contract?
or do you dynamically select, narrow, or extend that contract for a specific request?

That is the framing that matters.

The protocol shape you are actually building around

For a web app, the v0.9 lifecycle is fairly straightforward:

The server sends createSurface.
The server sends updateComponents.
The server may send updateDataModel.
The client renders the surface and sends actions back.
The server continues streaming updates as needed.

A minimal shape looks like this:

[
  {
    "version": "v0.9",
    "createSurface": {
      "surfaceId": "signup",
      "catalogId": "https://a2ui.org/specification/v0_9/basic_catalog.json",
      "sendDataModel": true
    }
  },
  {
    "version": "v0.9",
    "updateComponents": {
      "surfaceId": "signup",
      "components": [
        {
          "id": "root",
          "component": "Column",
          "children": ["title", "email", "submit"]
        },
        {
          "id": "title",
          "component": "Text",
          "text": "# Create account"
        },
        {
          "id": "email",
          "component": "TextField",
          "label": "Email",
          "value": { "path": "/user/email" }
        },
        {
          "id": "submit_label",
          "component": "Text",
          "text": "Continue"
        },
        {
          "id": "submit",
          "component": "Button",
          "child": "submit_label",
          "action": {
            "event": {
              "name": "submitSignup"
            }
          }
        }
      ]
    }
  }
]

The important implementation detail is that A2UI uses a flat list of components linked by IDs.
That is a good choice because it is easier to emit, easier to diff, and easier to validate for:

duplicate IDs
missing root
dangling references
cycles
orphaned components

Those are exactly the boring details that determine whether a generative UI system survives contact with production.

Strategy 1: Fixed schema

Fixed schema means your application chooses the catalog ahead of time and the model only emits valid instances of UI that conform to that contract.

This is the default I would recommend for most teams.

Use it when:

the workflow is business-critical
the UI shape is predictable
you want strong testability
analytics and event handling need to stay stable
you do not want renderer behavior drifting between requests

Examples:

onboarding flows
support triage
approvals
payments
account management
healthcare or compliance-heavy forms

These are not the places where you want model creativity.

Why fixed schema works

A fixed schema gives you a stable protocol boundary.
That buys you:

prompts are easier to reason about
examples are easier to curate
QA can build reusable fixtures
regressions are easier to reproduce
analytics stay more consistent
frontend behavior remains predictable

It also makes debugging much easier.
When something breaks, you are usually debugging a bad payload, not a drifting contract and a bad payload at the same time.

My rule of thumb

If the flow is revenue-critical, compliance-heavy, or operationally sensitive, start fixed.

You can always loosen the system later.
Going the other direction is usually painful.

Strategy 2: Dynamic schema

Dynamic schema is where things get more interesting.
It is also where teams get themselves into trouble.

What I mean by dynamic schema is not "let the model invent whatever UI primitives it wants."

That is not a schema strategy.
That is giving up.

In a production A2UI application, dynamic schema should still be renderer-owned.
The client needs to know how to render every component the model is allowed to reference.

So in practice, dynamic schema usually means one of three things:

Dynamic catalog selection from a trusted set
Dynamic use of client-advertised inline catalogs
Dynamic overlays that narrow or extend a trusted base catalog for a specific request

That third option is the one I would ship most often.

The dynamic pattern I recommend

Do not let the model generate a brand new universe from scratch.

Instead:

Start from a fixed trusted base catalog.
Let the model generate a task-shaped overlay.
Validate that overlay.
Merge it into the base contract for prompting and validation.
Fall back to the base contract if the overlay keeps failing.

This gives you flexibility without losing control.
Most products do not need unbounded UI generation.
They need a safe way to adapt a known renderer contract to the long tail.

Why validation is non-negotiable

A2UI v0.9 is more prompt-friendly.
It is not a security model.

If you allow a model to shape any part of the UI contract, then validation becomes part of the product, not an implementation detail.

At minimum, a serious pipeline should validate two things:

The schema contract itself
The final A2UI payload generated against that contract

That separation matters because a valid overlay does not guarantee a valid payload.

For dynamic schema in particular, I would validate:

overlay structure
component and property compatibility
child reference types
topology integrity
final payload instances against the selected catalog

Without this layer, dynamic schema quickly turns into "the backend forwards malformed intent and hopes the renderer is charitable."

The architecture I would actually ship

If I were building a fullstack agent web app around A2UI, this is the high-level policy I would use.

1. Fixed by default

Use a fixed catalog for the majority of flows.
Keep the happy path boring.

That is where stability and predictable UX come from.

2. Dynamic for the long tail

Use dynamic overlays only for workflows that are genuinely exploratory, tenant-specific, or too variable for one static prompt contract.

This keeps the flexible path available without making the whole system probabilistic.

3. Dynamic means task-shaped, not unbounded

Restrict dynamic behavior to things like:

narrowing allowed components
adding task-specific examples or constraints
selecting from trusted custom catalogs
merging safe overlays over a base catalog

Do not let the model invent component semantics the client never negotiated.

4. Validate, repair, retry, fallback

The loop should be:

Generate candidate overlay
Validate it
If invalid, feed the error back to the model
Retry a few times
Fall back to fixed if it still fails

I would cap retries at around five attempts.

Past that point, you are not repairing the schema.
You are negotiating with entropy.

At a high level, the control flow should look like this:

user request
  -> choose fixed or dynamic policy
  -> if dynamic:
       generate candidate overlay
       validate overlay
       if invalid:
         return validation error to model
         retry up to N times
       if still invalid:
         fall back to fixed catalog
  -> generate final A2UI payload
  -> validate final payload
  -> stream to client

The implementation should be just as explicit:

MAX_SCHEMA_ATTEMPTS = 5


def resolve_catalog(request_text: str, client_capabilities: dict | None):
    fixed_catalog = get_fixed_catalog(client_capabilities)

    if not should_use_dynamic_schema(request_text):
        return "fixed", fixed_catalog

    last_error = None
    last_overlay = None

    for _ in range(MAX_SCHEMA_ATTEMPTS):
        overlay = llm_generate_overlay(
            request_text=request_text,
            client_capabilities=client_capabilities,
            previous_error=last_error,
            broken_schema=last_overlay,
        )

        try:
            selected_catalog = validate_overlay(overlay, client_capabilities)
            return "dynamic", selected_catalog
        except Exception as exc:
            last_error = str(exc)
            last_overlay = overlay

    return "fallback-fixed", fixed_catalog

5. Validate the final payload too

Even after the schema contract passes, validate the generated A2UI payload before it reaches the client.

Schema validation and instance validation are separate responsibilities.
Treat them that way.

6. Cache successful overlays

If a task-shaped overlay validates and performs well for a repeated intent, cache it by tenant, task family, and capability set.

That reduces latency, prompt cost, and repeated schema thrash.

7. Treat all agent output as untrusted

This should be obvious, but it is still worth stating directly.

Agent messages, UI payloads, and model-shaped schema overlays are all untrusted input.

That means:

validation
sanitization
strict renderer boundaries
strong CSP and isolation where relevant
no casual trust just because the output happens to be JSON-shaped

A useful mental model

I think the cleanest way to reason about A2UI is this:

the renderer is trusted
the model is constrained
the backend is the enforcer
fallback is deterministic

That is the architecture.
Once you see it that way, the fixed-versus-dynamic decision gets much easier.

When to use which approach

My practical rule is simple.

Use fixed schema when you want reliability.
Use dynamic overlays when variability is real and the value justifies the complexity.

In practice:

fixed for core trusted workflows
dynamic for the long tail

Per surface, not per company.

Conclusion

A2UI v0.9 is a meaningful step forward for agent-driven interfaces.

The flatter structure, prompt-first posture, swappable catalogs, and explicit lifecycle make it much more usable than older "generate a giant nested object and pray" approaches.

But the big lesson is not that everything should become dynamic.
The big lesson is that agent-driven UI still needs architecture.

The posture I would use is:

fixed schemas for stable, high-confidence workflows
dynamic overlays for the long tail
strict validation in the middle
repair loops for recoverable failures
deterministic fallback when the model cannot produce a safe contract

That gives you flexibility without surrendering control.
And in agent systems, control is the thing that lets creativity survive production.

References

The Frontend Reward Loop for Agentic Software

Brian Love — Wed, 18 Mar 2026 23:02:37 +0000

I have been thinking about this after reading the rLLM work on post-training language agents.

The big idea in that work is right: if agents are going to improve, they need a loop.
Not just inference.
A loop of action, feedback, and improvement.

What I want to argue in this post is simple:

The frontend is the best place to collect the heuristics for that loop.
Most teams should push prompt augmentation much further before training an offline reward model.

tl;dr

Agent quality is now a feedback-loop problem, not only a model-size problem.
The frontend is the only place where intent, correction, and outcome are visible together.
Product heuristics can drive real gains without starting with offline reward-model training.
Prompt augmentation gets most teams very far on short and medium-horizon workflows.
Move to offline RL only when prompt gains flatten or long-horizon credit assignment becomes the bottleneck.

Fullstack Agentic Applications

Be sure to check out the Angular Agent Framework for building fullstack agentic applications.

From static intelligence to live behavior

Reasoning models can do very well on static tasks.
Agentic software lives in dynamic tasks.

That means we care less about one-shot correctness and more about behavioral quality over a sequence of steps:

Did the system choose a sensible next action?
Did the user need to undo or rewrite it?
Did the workflow actually complete?

This is why post-training agents matter.
And this is why product teams need to treat interaction data as first-class infrastructure.

Why the frontend is the best reward surface

The backend can tell us what was called.
The model logs can tell us what token came next.
Only the frontend can reliably tell us whether the user felt the action was useful.

The frontend gives us a dense stream of behavior signals:

Accept vs reject
Minor edit vs full rewrite
One-shot completion vs retry loops
Continue vs abandon
Agent flow vs human escalation

These are not perfect labels.
They are heuristics.
But they are high signal and available immediately.

In practice, this is the best early reward surface most teams have.

A practical heuristic set

If I were starting today, I would implement four buckets.

1. Correction heuristics

Edit distance between agent output and final submitted value
Undo/revert frequency after agent actions
Manual overwrite rate

2. Friction heuristics

Time-to-next-meaningful-action
Retry count for same intent
Dead-end path frequency

3. Outcome heuristics

Task completion rate
Reopen/regression rate
SLA-aware completion time

4. Trust heuristics

Delegation rate for repeat tasks
Human escalation rate
Opt-out after poor outcomes

No single metric is enough.
A composite score is usually better than betting on one proxy.

The part I want to challenge: do we need offline reward models first?

Usually, no.

I think most teams can get much further than expected with prompt augmentation before training a separate reward model offline.

When I say prompt augmentation, I mean the full runtime strategy:

Better task framing
Better context packing from recent user behavior
Better tool constraints and checks
Better fallback prompts for low-confidence cases
Better routing between prompt variants

This is still behavior optimization.
It is just inference-time optimization.

For many product workflows, that is enough to unlock most early gains.

How far prompt augmentation gets us

Prompt augmentation gets us very far on:

Bounded workflows
Clear completion criteria
Frequent user corrections
Fast evaluation loops

Examples:

Internal support triage
Structured drafting and form completion
Actionable summarization
Multi-step UI workflows with explicit completion states

Where it starts to fail:

Long trajectories with delayed outcomes
Heavy credit assignment ambiguity
High cost/latency from complex inference-time strategies
Persistent instability across prompt variants

That is when offline trajectory training and RL become worth the investment.

Recommended rollout

If you are building agentic product features now, this is the sequence I would use:

Instrument frontend interaction events with stable task/session IDs.
Define a small heuristic scorecard (correction, friction, outcome, trust).
Use that scorecard to drive prompt and routing updates weekly.
Build an eval flywheel with holdouts and regression checks.
Introduce offline reward-model training only after improvements plateau.

This keeps teams moving quickly while preserving a path to deeper optimization.

Guardrails

None of this works well without guardrails.

At minimum:

Privacy-safe event collection
Anti-gaming checks for proxy metrics
Correctness-weighted objectives (not just speed)
Human review samples to calibrate heuristic drift

If we do not add guardrails, we optimize the dashboard instead of the product.

Closing

The backend can train the policy.
But the frontend is where the reward signal is born.

If we want agents that improve from real human interaction, we need to treat frontend behavior as training infrastructure.

And we should be honest about sequencing:
Start with prompt augmentation.
Push it hard.
Then add offline RL when the data proves you need it.

Using Angular & LangChain together?

Check out the the Enterprise Streaming Resource for LangChain and Angular

References

rLLM: A Framework for Post-Training Language Agents
rLLM Docs: rLLM Project Documentation
Sutton and Silver: [Welcome to the Era of Experience](https://storage.googleapis.com/deepmind-media/Era-of-Experience%20/The%20Era%20of%20Experience%20Paper.pdf

The Landscape of Generative UI in 2026

Brian Love — Wed, 18 Mar 2026 23:02:36 +0000

Generative UI is no longer just "chat that can answer questions."

In 2026, it is a product and architecture decision.

In this post, I want to give a practical framework I keep coming back to:

Chat Components
Component Systems
Embedded Generative UI

tl;dr

Generative UI is a spectrum, not a single implementation pattern.
Each pattern optimizes for a different balance of control and flexibility.
Most teams should mix patterns by surface area, not pick one globally.

Why this matters now

The first wave of AI products proved that people will use chat interfaces.
The next wave is about execution: helping users actually complete work.

Text-only responses are often too slow for real workflows.
Users need affordances to compare options, edit inputs, and take action with confidence.

That is where Generative UI becomes useful: it converts intent into usable interface.

What Generative UI is

Generative UI is UI that is selected, composed, or embedded at runtime based on user intent and agent reasoning.

It is not "markdown in a chat bubble."
It is a system where:

the model interprets intent
tools fetch or mutate state
the UI renders clear actions and state transitions

What I'm working on.

Before we go any further, I'd love to share that I am building Angular Agent Framework at cacheplane.ai

The spectrum

I think about this as More Control -> More Freedom:

Chat Components
Component Systems
Embedded Generative UI

These are complementary patterns.
You can (and often should) use all three in one product.

1) Chat Components

Chat Components are predefined UI blocks that the agent can invoke.
The frontend team still owns the component implementation and behavior.

Why teams start here

Fastest path to a reliable production experience
Strong control over brand and behavior
Easier trust and security posture from explicit contracts

Tradeoffs

New UI shapes still require frontend releases
Less flexible for novel, long-tail requests

Best fit

Core, high-trust, brand-critical flows.

2) Component Systems

Component Systems use schema-driven composition.
The model or backend provides structured payloads, and the frontend composes the screen from reusable primitives.

Why this pattern scales

Lower coupling between backend behavior and frontend rendering
Better coverage for long-tail UI permutations
Consistent visual system even with many generated layouts

Tradeoffs

More engineering investment up front
Less pixel-perfect than handcrafted, one-off UI

Best fit

Enterprise and platform surfaces with broad variability and repeatable primitives.

3) Embedded Generative UI

Embedded Generative UI is when a host app embeds external app surfaces and coordinates secure handoff between agent context and embedded execution.

Why teams adopt it

Maximum flexibility for specialized experiences
Natural path to ecosystem or app-platform strategies

Tradeoffs

Hardest developer experience
Inconsistent presentation across embedded surfaces
More complex security and permission design

Best fit

Super-host products where extensibility is part of the core value proposition.

Where this is already being used (verified examples)

The examples below are based on public product/docs updates and are accurate as of February 21, 2026.

Chat Components examples

OpenAI's Spring Update (May 13, 2024) states ChatGPT users can "analyze data and create charts," which is a concrete case of model responses invoking visual components inside chat.
Salesforce announced Agentforce Cards (March 5, 2025), where agents embed Lightning Web Components in responses.
Intercom's Fin answer cards update (January 27, 2025) is another example of structured, reusable UI cards rendered inline in conversational responses.

Component Systems examples

Microsoft Copilot Studio documents Adaptive Cards as JSON-defined custom UI, including inputs and submit actions, rendered in chat surfaces.
Microsoft 365 Copilot API documents Adaptive Card response templates, including static and dynamic templates that map cleanly to schema-driven composition.
Salesforce's adaptive response formats (for example rich choice and rich link) show a standardized response schema approach for composing predictable UI affordances.

Embedded Generative UI examples

OpenAI's Apps SDK reference describes components rendered in ChatGPT and connected through a window.openai bridge, with explicit iframe and CSP controls.
OpenAI's ChatGPT apps lessons learned (February 4, 2026) notes they built roughly two dozen apps and discusses practical iframe architecture patterns for hosted app experiences.
OpenAI's Introducing GPTs (November 2023) and the GPT Store help article document the host + app-store model in ChatGPT.
Anthropic's Artifacts overview and Artifacts support docs describe interactive, side-panel app-like outputs embedded directly in the Claude host experience.

Getting started: Hashbrown

If you want to implement Generative UI in a web app today with Hashbrown, the core pattern is:

Stream model output from your backend.
Register renderable components in the frontend.
Use useUiChat so assistant messages can include UI trees, not just text.

The official setup in Hashbrown docs/README is:

Install @hashbrownai/{core,react,openai}.
Wrap your app with HashbrownProvider.
Define model-callable components with exposeComponent.
Use useUiChat({ components: [...] }) to render those components in assistant responses.

import { HashbrownProvider, exposeComponent, useUiChat } from "@hashbrownai/react";
import { s } from "@hashbrownai/core";

function App() {
  const { messages, sendMessage } = useUiChat({
    model: "gpt-4.1",
    system: "You are a helpful assistant that can render UI components.",
    components: [
      exposeComponent(FlightCard, {
        name: "FlightCard",
        description: "Show a flight option card",
        props: {
          airline: s.string("Airline name"),
          price: s.string("Formatted ticket price"),
        },
      }),
    ],
  });

  // render messages and call sendMessage(...)
}

export function Providers({ children }: { children: React.ReactNode }) {
  return <HashbrownProvider url="/api/chat">{children}</HashbrownProvider>;
}

References:

Getting started: CopilotKit (v2 APIs)

For CopilotKit, a practical v2 path is:

Use the root <CopilotKit> provider to connect to your runtime.
Use v2 chat components (for example CopilotChat or CopilotSidebar).
Register v2 frontend tools with useFrontendTool and a render function for in-chat UI.

import { CopilotKit } from "@copilotkit/react-core";
import {
  CopilotChat,
  ToolCallStatus,
  useFrontendTool,
} from "@copilotkit/react-core/v2";
import { z } from "zod";
import "@copilotkit/react-core/v2/styles.css";

function ToolUIs() {
  useFrontendTool({
    name: "showFlightCard",
    description: "Display a flight option card in the chat UI",
    parameters: z.object({
      airline: z.string(),
      price: z.string(),
    }),
    handler: async ({ airline, price }) => `${airline} ${price}`,
    render: ({ args, status }) => {
      if (status !== ToolCallStatus.Complete) return <div>Loading card...</div>;
      return <FlightCard airline={args.airline ?? ""} price={args.price ?? ""} />;
    },
  }, []);

  return null;
}

export default function Page() {
  return (
    <CopilotKit runtimeUrl="/api/copilotkit">
      <ToolUIs />
      <CopilotChat agentId="travel-agent" />
    </CopilotKit>
  );
}

Notes for v2:

Keep hooks/components from @copilotkit/react-core/v2.
Import the provider from @copilotkit/react-core (as the v2 docs specify).
Use Zod schemas for v2 tool parameters.

References:

Choosing the right pattern

My practical rule: choose per surface, not per company.

Use Chat Components for trusted core workflows.
Use Component Systems for scalable, long-tail generation.
Use Embedded Generative UI only where ecosystem value clearly outweighs complexity.

Architecture notes that matter

Keep UI contracts owned by frontend.
Keep tool boundaries explicit (read, write, side effects).
Keep agent behavior portable across model providers.
Match security by pattern:
Chat Components: strict, typed contracts.
Component Systems: schema validation plus policy checks.
Embedded Generative UI: sandboxing, origin boundaries, and explicit permissions.

Implementation progression I recommend

Start with Chat Components for one critical workflow.
Add Component Systems for breadth and speed.
Add Embedded Generative UI selectively for ecosystem scenarios.

Keep one reference workflow (for example, flight booking) across all three stages.
It makes tradeoffs concrete and easier to explain to stakeholders.

Conclusion

Generative UI is not just a model capability.
It is a design and systems decision.

In 2026, the strongest strategy is intentional composition:

Start constrained.
Expand with structure.
Embed only where leverage is clear.

OpenClaw Setup, Configuration, and Key Takeaways

Brian Love — Wed, 18 Mar 2026 23:02:35 +0000

I set up OpenClaw on macOS with Telegram as my primary channel. The initial setup was quick, but I hit pairing and health-check failures that caused the first message to hang. This post captures what worked, what broke, and the operating policy I now use by default.

Environment

macOS desktop app + CLI
Node v22.14.0
OpenClaw 2026.2.19-2
Telegram bot channel enabled

1. Baseline setup

I started with the gateway and channel checks:

openclaw gateway probe
openclaw status --deep

That verified:

Gateway reachable on ws://127.0.0.1:18789
Telegram configured and healthy
Agent session available

2. Pairing the macOS app

My first blocker was:

gateway closed (1008): pairing required

I inspected pending and paired devices and approved the app request:

openclaw devices list --json
openclaw devices approve <request-id> --json

This ensured the macOS app had the expected auth state and roles.

3. Debugging "health check failed" and hanging sends

After pairing, the app still showed a failed health check and initial sends hung. The logs showed repeated health RPC failures tied to role auth behavior, which degraded responsiveness under load.

What helped most:

Comparing app behavior with app process stopped vs running
Watching gateway logs during connection attempts
Validating roles/tokens in device state before changing anything else

Key lesson: trust the logs over UI symptoms.

4. Stabilizing and re-validating

After correcting pairing/auth behavior, I re-ran validation:

openclaw gateway restart
openclaw gateway probe
openclaw status --deep

Final checks I care about:

Gateway RPC succeeds consistently
Telegram status is OK
No recurring pairing-upgrade loop
No repeating unauthorized health errors

Default security policy (what OpenClaw should always/never do)

This is the policy I now use as my default.

Always

Ask before risky actions; state what/why first.
Show exact files/commands changed.
Run relevant tests/lint before declaring done.
Redact secrets/tokens from output.
Ask clarifying questions when requirements are ambiguous.

Never (without explicit approval)

Destructive ops (rm -rf, git reset --hard, DB deletes, force-push).
Sending external messages (Telegram/email/webhooks) on my behalf.
Installing/updating system tools, packages, or services.
Accessing or exporting secrets/credentials.
Spending money or invoking paid APIs/services.

Key takeaways

Pairing roles must match real app behavior, not just initial connect success.
openclaw devices list --json is the fastest way to spot role mismatches.
Health checks are a real signal; if they fail, message send paths can stall.
Re-verify after every change with gateway probe and status --deep.
Strong boundaries reduce accidental risk while still keeping automation useful.

What I'm working on.

With openclaw I am working for cacheplane building the Angular Agent Framework

Building Web Applications We Can Trust - The Imperative of SRE

Brian Love — Sun, 11 Jun 2023 03:00:14 +0000

Building Web Applications We Can Trust - The Imperative of SRE

In this article, we explore the critical role of Site Reliability Engineering (SRE) for different types of SaaS owners and web developers, ranging from those overlooking reliability issues, those fighting to escape 'reliability hell', and those aware of the importance but lacking the resources to implement it.
We emphasize the necessity of SRE not just as a problem-solving method but as a culture, fostering a more reliable, trustworthy digital future.
We also introduce Polaris, an AI-powered tool designed to support and simplify the journey towards improved reliability.

In today's digital era, web application and Software-as-a-Service (SaaS) platforms dominate our interactions, dictating how we work, communicate, shop, and more.
As a result, reliability and trust have emerged as the most crucial features of these platforms.
In the throes of digital transformation, if there is one thing that every SaaS owner or web developer must focus on, it's Site Reliability Engineering (SRE).
Why? Let's explore.

Unresolved Reliability: Time Bomb or Opportunity?

The first group of SaaS owners and software engineers are those who are aware of reliability issues but opt to overlook them.
Their reasons may vary, from cost implications to rapid growth that seems to dwarf the need for reliability.
This can be a deceptive comfort zone, the mirage of a thriving business masking an impending reliability catastrophe.
Yes, you might have strong consumer lock-in, and your business might be on a steep growth curve.
However, remember this: trust, once lost, is hard to regain.

Consider what's at stake: your reputation, customer loyalty, and ultimately, your bottom line.
The need for reliability isn't a business choice —- it's a business imperative.
Don't wait for the time bomb to detonate; use the ticking to turn it into an opportunity.
By implementing SRE best practices now, you can preemptively address potential reliability issues and strengthen user trust, providing you with a competitive edge in the market.

The Long Journey Out of Reliability Hell: A Crucible for Change

The second group comprises SaaS owners and engineers painfully aware that they are in what we call "reliability hell".
You may be experiencing high churn rates, customer complaints, and even plummeting profits.
Getting out of reliability hell is indeed a Herculean task.
It takes time, effort, and significant investment in SRE best practices, tools, and processes.
Yet, it's a task worth undertaking, a crucible that can forge a more resilient and trusted business.

By embracing SRE, you are not just rectifying issues, but more importantly, you're establishing a culture of reliability within your organization.
This culture is a game-changer.
It ensures that reliability is built into the DNA of your applications, not bolted on as an afterthought.
It fosters an environment where every code, every deployment, every update is geared towards enhancing reliability.

Acknowledging the Need for SRE: A Call to Arms

Lastly, there are those SaaS owners and developers who are acutely aware of the need for reliability but find themselves unprepared to take it on.
The challenges of knowledge, skills, and resources can indeed be daunting.
But remember this: admitting the problem is the first step to the solution.

Fortunately, you're not alone in this journey.
Tools like Polaris, an AI-powered site reliability tool, can be invaluable.
Polaris is designed to detect outages and incidents in your web application in real time, helping you to navigate the complexities of SRE, even with limited resources.

Our vision for Polaris is simple: to help you build applications that people trust.
Because in a world reliant on digital, trust and reliability are the true currencies of success.

If you're ready to steer your web application or SaaS business towards a more reliable, more trusted future, we invite you to explore Polaris.
Polaris is currently in beta and we'd love for you to be part of our journey.
Feel free to sign up for Polaris, or contact us to learn more.

Together, we can build a world of reliable and trusted web applications.

Embracing Site Reliability Engineering

Brian Love — Wed, 10 May 2023 03:38:41 +0000

Site Reliability Engineering (SRE) is transforming the way software teams approach reliability and performance in modern web applications.
With an increasing number of frontend-focused engineers, it's essential to understand the fundamentals of SRE and implement a culture of reliability within your team and organization.
This blog post will introduce you to the basics of Site Reliability Engineering, its importance for software engineers and managers, and provide some best practices to kickstart your journey towards a more reliable web application.

What is Site Reliability Engineering?

Site Reliability Engineering is a discipline that combines aspects of software engineering and operations to build and maintain scalable and reliable systems.
Pioneered by Google, SRE focuses on automating infrastructure management, ensuring service reliability, and optimizing performance.
SRE emphasizes the use of Service Level Objectives (SLOs) and Error Budgets as a means to balance feature development, system stability, and user experience.

Why Should Software Engineers and Managers Be Concerned with Reliability?

Reliability is crucial for the success of any web application.
A reliable application ensures a positive user experience, leading to higher user retention, satisfaction, and ultimately, revenue.
As a software engineer or manager, it's your responsibility to ensure that your application is stable, performant, and consistently meeting the needs of your users.
Embracing SRE principles can help you identify and address performance bottlenecks and system failures, reducing downtime and improving overall system resilience.

Best Practices for Building a Culture of Reliability

First, define clear Service Level Indicators (SLIs) and Service Level Objectives (SLOs). SLIs are metrics that quantify your system's performance, while SLOs are target values for those metrics.
Establishing clear SLIs and SLOs helps your team set realistic goals for system reliability and provides a measurable way to track progress.
Ensure that these metrics are aligned with your users' expectations to maintain a high-quality user experience.

Second, implement monitoring and observability.
Monitoring and observability are crucial for understanding your system's health and performance.
Invest in tools that provide real-time insights into your application's performance and enable you to identify potential issues quickly.
Polaris, an AI-powered site reliability platform, is an excellent example of a solution that helps you effectively monitor and gain observability into your web applications' performance and reliability.

Third, automate incident response and management.
Automate processes for detecting, triaging, and resolving incidents to minimize the impact on your users.
Integrating your monitoring tools with incident management solutions, such as PagerDuty or Jira, can help streamline the process and reduce time to resolution.

Fourth, embrace a blameless culture.
Encourage a culture of learning and continuous improvement by treating failures as opportunities to learn rather than assigning blame.
Conduct blameless postmortems to identify the root causes of incidents and implement preventive measures to avoid recurrence.

Fifth, continuously iterate and improve.
Continuously evaluate and refine your processes, tools, and infrastructure.
Keep your team informed about best practices, and encourage open communication and collaboration to foster a culture of learning and improvement.

Conclusion

Site Reliability Engineering is a powerful approach to ensuring the reliability and performance of your web applications.
By understanding its fundamentals and adopting SRE best practices, you can build a culture of reliability within your team and organization, ultimately leading to more satisfied users and a successful web application.
Start your journey towards a more reliable web application today by embracing the principles of Site Reliability Engineering and leveraging the power of tools like Polaris to gain observability and insights into your system's performance.

Polaris

Building a culture of site reliability is critical to the success of an organization, especially if you are a SaaS product. But, it can be hard to climb out of reliability hell.

My team is building an AI-powered Site Reliability Platform that helps SaaS companies build apps people trust by increasing the reliability and performance of your web apps. We're currently in a closed-beta. However, don't fret, you can sign up for our beta and help us build a platform that changes the way we think about site reliability.

Typed Forms in Angular

Brian Love — Thu, 20 Oct 2022 18:47:47 +0000

Angular version 14 is a feature-packed release that brings new APIs, functionality, and a developer experience.
This includes one of the most requested feature improvements in Angular: typed forms.

In this article, you'll learn:

How to migrate to the new strongly-typed forms API in Angular version 14
Typed a FormControl
Typed a FormGroup
Typed a FormArray
New FormRecord
Mixing typed and untyped controls
Non-nullable controls

Let's dive in!

Typed Forms API FTW 🎉

If you have been using Angular's forms API, whether template-based or reactive forms, you likely have noticed that prior to Angular 14 much of the API surface had a lot of any types.

Angular (version 2, not AngularJS) was released in September of 2016 (after Flash died but before build tools took the world by storm). Not long after the release, developers started to note that the API was both not type-safe (or null-safe).
In fact, the most upvoted and commented on issue in the GitHub repository was created December of 2016 to report this problem.

Angular 14 introduces reactive form APIs that are both type-safe and null-safe. This is a big win for using reactive forms in Angular.
Unfortunately, the template-driven forms API is currently not strongly typed.

Migrating to Angular 14

To get started, you need to update your project to use Angular 14 to take advantage of the new APIs.

ng update @angular/cli @angular/core

Once your project is updated, you'll not that instance of FormControl and FormGroup have been migrated to the untyped classes:

FormControl is migrated to UntypedFormControl
FormGroup is migrated to UntypedFormGroup

Typed `FormControl`

In Angular 14, the FormControl class now has a TypeScript generic type of TValue whose default type assignment is any. What does this mean?

Prior to Angular 14, when accessing properties such as value the type was any, and when using the method setValue, it would accept any argument value.

Here are just a few of the class members that have been updated to use the TValue generic type:

setValue(value: TValue)
patchValue(value: TValue)
reset(formState: TValue)
getRawValue(): TValue
value: TValue

This is a big win for preventing runtime exceptions and regressions due to type errors!

It's important to note that the TValue generic type is inferred by TypeScript when newing-up a new FormControl instance, so it's not necessary to specify the generic type.
Let's look at an example.

const control = new FormControl('Mike');

Note, we did not specify the TValue generic type above.
Rather, the type is inferred by the value argument specified to constructor function when creating a new instance of the FormControl class.

Typed `FormGroup`

The purpose of Angular's FormGroup is to group form controls logically in order to track their state (value, validity, etc.) together.
Angular 14 also introduces updated typings for the FormGroup API.

Let's look at an example.

interface SignUpForm {
  name: string;
  email: string;
  subscribe?: string;
}

const signUpFormGroup = new FormGroup<SignUpForm>({
  name: new FormControl(''),
  email: new FormControl('')
});

Let's quickly review the code above:

First, we define a new SignUpForm interface.
The interface is only necessary if we have optional form controls. In this example, the subscribe control can be dynamically added and removed from the group.
Next, we create a new FormGroup instance, and since we have an optional control, we specify the generic type to the SignUpForm interface.
The name control's value is typed: string | null
The email control's value is typed: string | null
The subscribe control value is typed: string | null | undefined
The signUpFormGroup value is typed: Partial<{ name: string | null; email: string | null; subscribe: string | null | undefined }>

You may have noticed that the control values can be null or, if optional, undefined.
This is because Angular's form APIs allow for null values.
For example, if we invoke the reset() method on a control, the value is not set to the original/seed value, rather, it is set to null.
We'll show how to override this behavior below.

It should also be noted that the TValue for each control is also inferred as we previously learned.

Typed `FormArray`

Currently, TypeScript arrays are homogeneous.
This means that TypeScript expects that every item in an array is of the same type (including any).
For the sake of clarity, this is not to be confused with tuples which can have unambiguous types.

With that said, typed FormArray instances require that all controls are homogeneously typed.
If a FormArray requires heterogeneous types then the use of the UntypedFormArray is recommended.

In this example we'll create a new FormArray with an initial control.

lineItems = new FormArray([
  new FormControl('')
]);

Because we have defined the FormArray to include a control whose TValue is a string, the type of the array is inferred as: FormArray<AbstractControl<string, string>>.
The compiler now expects that each item in the array is a control whose TValue is a string.

If we attempt to add a new control to the array whose TValue is not a string, the compiler will throw an exception indicating:

lineItems.push(new FormControl(0));

The compiler exception indicates that there is an error.

Argument of type 'FormControl<number>' is not assignable to parameter of type 'AbstractControl<string, string>'.
Types of property 'value' are incompatible.
Type 'number' is not assignable to type 'string'.

This is a good thing! 😌

Ok, but what if our array of controls is initially empty?
In that case, we can specify the generic type of the controls:

lineItems = new FormArray<AbstractControl<string>>([]);

In the example above, we use the AbstractControl type and specify the TValue to be of type string as we expect every control's value to be a string.

New `FormRecord`

As we learned previously the FormGroup in Angular 14+ supports specifying a group of controls whose TValue types are known when creating the group, even when creating optional controls within the group.
However, what about a group of controls whose TValue is not known when creating the group.
To meet this use case, Angular 14 ships with a new FormRecord class.

Let's look at an example.

formGroup = new FormRecord<AbstractControl<string>>({});

Now that we have created the group of controls using the FormRecord class, we can start to add (and/or remove) controls from the group.

formGroup.addControl('street', new FormControl(''));

This code works as expected.
A new control is added to the group that meets the type definition.
However, what happens if we attempt to add a new control whose TValue is a number?

this.formGroup.addControl('no', new FormControl(0));

Again, the compiler throws an exception indicating that we cannot add this control to the group due to the type constraints.

Argument of type 'FormControl<number>' is not assignable to parameter of type 'AbstractControl<string, string>'.
Types of property 'value' are incompatible.
Type 'number' is not assignable to type 'string'.

The UntypedFormGroup class supports the user requirements in the event that we need a group of controls whose values are heterogeneous.

Mixed Types

We can declare mixed types of controls when working with a group of controls of heterogeneous types as long as we declare the controls when creating the group.
Further, we can use the UntypedFormControl class to declare a control whose TValue type is any (under the hood, this is a type whose generic type is preset to any).

Let's look at an example.

export class AppComponent implements OnInit  {
  formGroup = new FormGroup({
    street: new FormControl(''),
    no: new FormControl(0),
    postalCode: new UntypedFormControl()
  });

  ngOnInit(): void {
    const street = this.formGroup.value.street;
    const no = this.formGroup.get('no').value;
    this.formGroup.get('postalCode').setValue(12345);
    this.formGroup.get('postalCode').setValue('ABC123');
  }
}

This all works as we expect.
We have a few controls, each with their own TValue, including the untyped control whose TValue is any.

Non-nullable Controls

If you recall from earlier, we mentioned that resetting a form control state will set the value to null, not the initial/seed value as we might expect.
With non-nullable form controls, we can explicitly instruct the compiler that the value is reset to the initial value when invoking the reset() method.

Let's look at an example

export class AppComponent implements OnInit {
  formGroup = new FormGroup({
    street: new FormControl('', { nonNullable: true })
  });

  ngOnInit(): void {
    this.formGroup.get('street').reset();
    const street = this.formGroup.value.street;
    console.log(street); // empty string, NOT null
  }
}

Key Takeaways

There are a few key takeaways when using Angular 14's updated forms API:

The FormControl, FormGroup, and FormArray signatures have been updated to support TypeScript generics.
The TValue type is inferred where possible.
FormGroup supports enumerated, homogeneous, and optional controls.
FormRecord supports non-enumerated (dynamic) and homogenous controls.
UntypedFormControl is a non strongly-typed FormControl. Or, in other words, the TValue type is preset to any.
UntypedFormGroup is a non strongly-typed FormGroup.
FormArray supports homogeneously typed controls.
UntypedFormArray is a non strongly-typed FormArray.
The nonNullable supports resetting a control state to the initial/seed value.
Through strict types and template type checking, we can avoid runtime exceptions and reduce regressions.

Need Help?

Do you have questions? We can help! LiveLoveApp provides angular consulting. We can answer your questions, perform an architecture review of your application and help you to implement best practices to improve your software development performance.

React Hooks with RxJS and Axios

Brian Love — Wed, 24 Aug 2022 21:14:42 +0000

Reactive Extensions for JavaScript, or RxJS, is a library that has a twofold purpose.
It creates an Observable primitive that is either synchronous or asynchronous, and it includes a rich library of functions that can be used to create observables, transform, filter, join, and multicast observables, provides error handling, and more.

If that sounds like a lot - it is.

While RxJS is commonly used in Angular projects due to the fact that it is a peer dependency, it can be overlooked by software engineers building applications using React - or other frontend JavaScript frameworks for that matter.

Let me be clear - you do not need to use RxJS with React.

Promises, the useEffect() hook, and libraries such as Axios provide much of what a typical React application requires for asynchronicity and fetching data.
What RxJS with React does provide is the ability to write pure functions for event streams, effectively handle errors within a stream of data, and easily fetch data using the native Fetch and WebSocket APIs.

In this article, I'd like to share how we use RxJS with React at LiveLoveApp for rapidly developing prototypes and applications for our clients.

Using `fromFetch()`

One advantage to using RxJS is the provided fromFetch() function that uses the native Fetch API with a cancellable AbortController signal.

Let's look at how you might use Axios for cancellation:

import { get } from "axios";
import { Button } from "@mui/material";
import { useCallback, useEffect, useState } from "react";

export default function App() {
  const [user, setUser] = useState(null);
  const controller = new AbortController();

  useEffect(() => {
    const id = 2;
    get(`https://reqres.in/api/users/${id}`, {
      signal: controller.signal
    }).then((response) => {
      try {
        setUser(response.data.data);
      } catch (e) {
        console.error(`Error fetching user`);
      }
    });
  }, []);

  const handleOnCancel = useCallback(() => {
    controller.abort();
  }, []);

  return <Button onClick={handleOnCancel}>Cancel</Button>;
}

Let's quickly review the code above:

First, we create a new instance of the AbortController class.
Then, as a side effect, we use Axios' get() method to fetch a user from the API, providing the AbortController's signal.
Finally, in the handleOnCancel() callback function we invoke the abort() method on the AbortController instance to cancel the fetch request.

When using RxJS's fromFetch() function it is not necessary to wire up an AbortController signal.
Rather, we can cancel the fetch request by emitting either an error or completion notification.

import { Button } from "@mui/material";
import { useCallback, useEffect, useState } from "react";
import { Subject } from "rxjs";
import { fromFetch } from "rxjs/fetch";
import { concatMap, takeUntil, tap } from "rxjs/operators";

export default function App() {
  const [user, setUser] = useState(null);
  const cancel$ = new Subject();

  useEffect(() => {
    const id = 2;
    const subscription = fromFetch(`https://reqres.in/api/users/${id}`)
      .pipe(
        tap((response) => {
          if (!response.ok) {
            throw new Error(response.statusText);
          }
        }),
        concatMap((response) => response.json()),
        tap(user => setUser(user)),
        takeUntil(cancel$)
      )
      .subscribe();
    return () => subscription.unsubscribe();
  }, []);

  const handleOnCancel = useCallback(() => {
    cancel$.next();
  }, []);

  return <Button onClick={handleOnCancel}>Cancel</Button>;
}

Let's review the code above:

First, we use the fromFetch() function from RxJS to use the native Fetch API to request a user. This function returns an Observable, that when subscribed to, will initiate the request.
Within the pipe() method, we first check if the response failed, and if so, we emit an error notification of the response's statusText.
Next, using the concatMap() operator, we merge the next notification that is emitted from the Observable created internally from the Promise returned from the .json() method.
Next, we use the takeUntil() operator to notify the outer Observable to complete, and abort the request if necessary, when the cancel$ subject emits a next notification.
Finally, within the handleOnCancel() callback function we invoke the next() notification on the cancel$ Subject.

The key takeaways are:

RxJS provides functions for interfacing with the native Fetch and WebSocket APIs using asynchronous Observables.
The fromFetch() operator uses the AbortController internally and cancels the request if the Observable either completes or an error notification is emitted.

How do I handle subscriptions?

It's best to clean up any subscriptions in our application when using RxJS.
While there are a few different approaches to ensuring an Observable that is subscribed to is completed (or unsubscribed from), one method is to invoke the .unsubscribe() method on the Subscription instance that is returned from the subscribe() function.
The teardown function returned from the useEffect() hook is our opportunity to perform any cleanup from the side effect.

De-bouncing an input stream

In this example, we will manage a search$ Observable stream that is denounced before we invoke the onSearch() callback function that is prop to the component.
While we could simply invoke the onSearch() callback function on each change to the input value, we want to avoid excessive network requests and repaints in the browser.

import CancelIcon from "@mui/icons-material/Cancel";
import SearchIcon from "@mui/icons-material/Search";
import { IconButton } from "@mui/material";
import { useEffect, useMemo, useState } from "react";
import { BehaviorSubject } from "rxjs";
import { debounceTime, tap } from "rxjs/operators";

export default function Search(props) {
  const { onSearch } = props;
  const [search, setSearch] = useState("");
  const search$ = useMemo(() => new BehaviorSubject(""), []);

  useEffect(() => {
    search$.next(search);
  }, [search]);

  useEffect(() => {
    const subscription = search$
      .pipe(debounceTime(1000), tap(onSearch))
      .subscribe();
    return () => subscription.unsubscribe();
  }, []);

  return (
    <div>
      <input
        type="text"
        placeholder="Search"
        onChange={(event) => setSearch(event.target.value)}
        value={search}
      />
      {search$.value && (
        <IconButton onClick={() => setSearch("")}>
          <CancelIcon />
        </IconButton>
      )}
      {!search$.value && <SearchIcon />}
    </div>
  );
}

Let's review the code above:

We have defined a search$ BehaviorSubject with an initial seed value of an empty string.
When the search state changes the next() method is invoked on the search$ subject with the current value.
We subscribe to the search$ Observable stream and use the debounceTime() operator to debounce the value changes of the search HTMLInputElement. Within the useEffect() hook we return the teardown callback function that will invoke the unsubscribe() method.

This implementation highlights the use of RxJS to manage a stream of data within our application from the onChange event that is caused by the user interacting with a search input.

The `useRxEffect()` Hook

Finally, I'd like to share a simple hook that LiveLoveApp uses for our React applications that depend on RxJS.
This hook makes it easy to not worry about subscriptions.

Let's take a look.

import { useEffect } from 'react';
import { Observable } from 'rxjs';

export function useRxEffect(factory: () => Observable<any>, deps: any[]) {
  useEffect(() => {
    const subscription = factory().subscribe();
    return () => subscription.unsubscribe();
  }, deps);
}

The useRxEffect() hooks is intentionally similar to the useEffect() hook provided by React.
The hook expects the factory function to return an Observable that is unsubscribed when the effect teardown callback function is invoked.

Here is a snippet of using the useRxEffect() hook based on the previous code:

import CancelIcon from "@mui/icons-material/Cancel";
import SearchIcon from "@mui/icons-material/Search";
import { IconButton } from "@mui/material";
import { useEffect, useMemo, useState } from "react";
import { BehaviorSubject } from "rxjs";
import { debounceTime, tap } from "rxjs/operators";

export default function Search(props) {
  const { onSearch } = props;
  const [search, setSearch] = useState("");
  const search$ = useMemo(() => new BehaviorSubject(""), []);

  useEffect(() => {
    search$.next(search);
  }, [search]);

  useRxEffect(() => {
    return search$.pipe(debounceTime(1000), tap(onSearch));
  }, []);

  return (
    <div>
      <input
        type="text"
        placeholder="Search"
        onChange={(event) => setSearch(event.target.value)}
        value={search}
      />
      {search$.value && (
        <IconButton onClick={() => setSearch("")}>
          <CancelIcon />
        </IconButton>
      )}
      {!search$.value && <SearchIcon />}
    </div>
  );
}

In the example code above, note that we have replaced the useEffect() hook with our custom useRxEffect() hook to manage the subscribing and unsubscribing from the search$ Observable.

Key Takeaways

If you're considering using RxJS in an existing or new React application, here are some key takeaways based on our experience:

RxJS is not necessary to build robust React application.
RxJS provides a functional programming implementation for building React applications with event streams, asynchronous data, and more.
RxJS implements the Observable primitive that is compatible to Promises (but without async/await).
RxJS has a rich library of functions for creating Observables, data transformation and multicasting, handling errors, and more.
You can think of RxJS as lodash for events.

AG Grid Cell Rendering Pipeline with TypeScript

Brian Love — Wed, 27 Jul 2022 16:05:00 +0000

Here at LiveLoveApp, we’re big fans of AG Grid - the best JavaScript grid in the world. In fact, we offer AG Grid implementation services based on our expertise!

Why?

For two primary reasons: performance and extensibility.
Many of our clients use AG Grid to meet customer requirements for displaying tabular data.

In this article you’ll learn:

The AG Grid cell rendering pipeline
How to leverage the new TypeScript generics provided by the AG Grid API (released in version 28)
How to create a type-safe value getter to retrieve the value for a cell
How to create a type-safe value formatted to format the value of a cell
How to create a type-safe and performant cell renderer

AG Grid Cell Rendering Pipeline

Without any customization and in the simplest form, each cell in AG Grid is rendered as a string based on the field specified in the provided row data.
However, often times an AG Grid implementation is not this simple.
This is where we can leverage the pipeline for rendering cells:

valueGetter()
valueFormatter()
cellRenderer()

Demo or it didn't happen

Here is a demo using React:

And, here is a demo using Angular:

Using the `valueGetter()` callback function

First, we can use a valueGetter() to fetch and/or mutate data in a cell using a provided callback function.
Let’s take a quick look at an example.

In this example, the requirement is to create a value getter that is type-safe and uses the data provided to AG Grid to conditionally multiply a value within our data set.

export const multiplierValueGetter =
  <T extends Record<TKey, number>,
    TKey extends string | number | symbol = string>(
    value: keyof T,
    multiplier: keyof T
  ) =>
    (params: ValueGetterParams<T>): number => {
      if (params.data === undefined) {
        return 0;
      }
      return Math.round(params.data[value] * params.data[multiplier] * 100) / 100;
    };

Let’s review the code above:

First, we declare the multiplierValueGetter() higher-order function. Using a higher-order function enables us to define the generic type T that extends a Record whose values are of type number. The higher-order function will return the value getter function that will be invoked by AG Grid with provided ValueGetterParams<T>.
The multiplierValueGetter() has two required parameters, first, the value property, and second, the multiplier property, both of which are keys of the data provided to the grid that is of type T.
Because we are using AG Grid v28 (or greater) we can specify the generic type of T for the ValueGetterParams. Prior to version 28, this generic type was not available, and as a result the type definition for the data property was any.
Within the value getter function, if data is undefined, which can be the case when using infinite row model or row grouping in AG Grid, we return 0.
Finally, we can round the value after multiplying.

Here is an example implementation of our multiplierValueGetter() higher-order function.

interface RowData {
  value: number;
  multiplier: number;
}

type Props = {
  rowData: RowData[]
}

export default function Grid ({ rowData }: Props) {
  const colDefs = [
    {
      colId: 'value',
      headerName: 'Value',
      field: 'value'
    },
    {
      colId: 'multiplied',
      headerName: 'Multiplied',
      valueGetter: multiplierValueGetter<RowData>('value', 'multiplier')
    }
  ] as ColDef<RowData>[];

  return (
    <AgGridReact
      className="ag-theme-material"
      columnDefs={colDefs}
      rowData={rowData}
    />
  );
}

Using the `valueFormatter()` callback function

After the cell value is known, the optional valueFormatter() callback function enables us to format the value.
Let’s look at an example of using the valueFormatter() callback function.

In this example, the requirement is to declare a reusable decimalValueFormatter() higher-order function that is type-safe and formats the specified data property to a specified length.

export const decimalValueFormatter =
  <TData, TValue>(digits = 0) =>
    (params: ValueFormatterParams<TData, TValue>): string => {
      const formatter = new Intl.NumberFormat('en-US', {
        minimumFractionDigits: digits,
        maximumFractionDigits: digits,
      });
      if (params.value === undefined) {
        return formatter.format(0);
      }
      return formatter.format(Number(params.value));
  };

Let’s review the code above:

We have declared a decimalValueFormatter() higher-order function. This enables the implementation of this value formatter to specify two generic types: TData and TValue. The generic of TData represents the type for the data parameter, and the generic of TValue represents the type for the value parameter. Our higher-order function has an optional digits parameter that specifies the min and maximum number of digits for the decimal formatting. The higher-order function returns a function that is the value getter that is invoked by AG Grid with the ValueGetterParams<TData, TValue> object.
In this value formatter, we are using the Intl.NumberFormat class to create a new formatter instance, specifying the minimum and maximum number of fraction digits.
If the data is undefined, which can be the case when using infinite row model or row grouping in AG Grid, then we simply return 0.
Otherwise, we return the formatted value.

Here is an example implementation of our decimalValueFormatter() higher-order function.

interface RowData {
  value: number;
  multiplier: number;
}

type Props = {
  rowData: RowData[]
}

export default function DashboardGrid ({ rowData }: Props) {
  const colDefs = [
    {
      colId: 'value',
      headerName: 'Value',
      field: 'value'
    },
    {
      colId: 'multiplied',
      headerName: 'Multiplied',
      valueGetter: multiplierValueGetter<RowData>('value', 'multiplier'),
      valueFormatter: decimalValueFormatter<RowData, Pick<RowData, 'taxRate'>>(2)
    }
  ] as ColDef<RowData>[];

  return (
    <AgGridReact
      className="ag-theme-material"
      colDefs={colDefs}
      rowData={rowData}
    />
  );
}

Using the `cellRenderer()` callback function

After the value for a cell is determined, and we have optionally formatted the value, we can use a cell renderer to have full control of how a cell is rendered in AG Grid.
By default, all values are rendered as a string.
In order to render a cell other than a string, we can use a custom cell renderer.

It’s important to note that we should only use a cell renderer when necessary.
By default, the textContent of the cell HTML element is set to the (optionally formatted) value.
When we are using a cell renderer we are adding additional elements, event listeners, etc. to the DOM, all of which must be rendered for each cell in the grid.

Finally, we recommend that all cell renderers strictly use vanilla JS.
This will improve the paint performance of your application when scrolling the grid.
Why is that?
If you use a framework (e.g. React, Angular, or Vue) then as a result each time the cell needs to be rendered, AG Grid must switch the context to a React (or Angular or Vue) application context in order to render the resulting HTML to the DOM. This can be very expensive and is often not necessary.

📣 Only use a cell renderer when necessary, limit the elements and event listeners to a minimum, and always use vanilla JS.

To configure a cell renderer we can provide AG Grid with:

A string that references a registered framework component
A class that implements the ICellRendererComp interface
A function that is invoked with the ICellRendererParams object

Let’s look at an example. In this example, the user requirement is to display a column with a name that is optionally abbreviated, and, when a user clicks on the name, we want to open a dialog (which will not be the responsibility of AG Grid, but we need to notify the consumer that the user has clicked on the name).

First, let’s define a new interface that describes the contract between the implementation and the cell renderer for the data that is expected.

export interface NameCellRendererData {
  id: string;
  name: string;
}

Next, let’s define another interface for the click event that will notify the implementation that the user has clicked on the name.

export interface NameCellRendererClickEvent<T, E = Event> {
  event: E;
  data: T;
}

The NameCellRendererClickEvent describes the event handler object that will be provided to a click parameter that is implemented when using the cell renderer.
The interface has two generics:

First, we define a generic of T that will be provided for the row data.
Second, we have a generic of E that has a default assignment to the global Event interface. In the cell renderer we can set a type that is narrower.

Now, let’s define another interface for the parameters that will be provided to the cell renderer.

export interface NameCellRendererParams<T> {
  click: (event: NameCellRendererClickEvent<T>) => void;
  document: Document;
  isAbbreviated?: (params: ValueGetterParams<T>) => boolean;
}

A few things to note:

First, we have declared the generic type of T in order to maintain type checking of the params object that is invoked for the isAbbreviated function.
The click parameter will be a callback function that is invoked by the cell renderer. The callback function is invoked with an event parameter that is the NameCellRendererClickEvent interface.
The isAbbreviated parameter is another callback function that enables the implementing grid to determine if a specific cell value should be abbreviated. We'll use the ValueGetterParams interface provided by AG Grid to keep our API ergonomic (in that we expect the developer to be aware of this existing interface, so it makes sense to use it).

Having described the API, let’s look at the code for the cell renderer.

type Params<T> = NameCellRendererParams<T> & ICellRendererParams<T, string>;

/**
 * AG Grid cell renderer for a user name.
 */
export class NameCellRenderer<T extends NameCellRendererData>
  implements ICellRendererComp<T>
{
  /** AG Grid API. */
  private api: GridApi | null = null;

  /** The button element. */
  private btnEl: HTMLButtonElement | null = null;

  /** Provided callback function that is invoked when the button is clicked. */
  private click:
    | ((event: NameCellRendererClickEvent<T, MouseEvent>) => void)
    | null = null;

  /** The column definition. */
  private colDef: ColDef;

  /** The AG Grid column. */
  private column: Column | null = null;

  /** AG Grid Column API. */
  private columnApi: ColumnApi;

  /** AG Grid context. */
  private context: any;

  /** The provided data. */
  private data: T | undefined;

  /** The global document. */
  private document: Document | null = null;

  /** Execution context bound function when the button is clicked. */
  private handleClick:
    | ((this: NameCellRenderer<T>, event: MouseEvent) => void)
    | null = null;

  /** Callback function to determinate if the name is abbreviated. */
  private isAbbreviated?: (params: ValueGetterParams<T>) => boolean;

  /** AG Grid row node. */
  private node: RowNode;

  /** The user name. */
  private value: = '';

  /** Value getter params to be provided. */
  get valueGetterParams(): ValueGetterParams<T> {
    return {
      api: this.api,
      colDef: this.colDef,
      column: this.column,
      columnApi: this.columnApi,
      context: this.context,
      data: this.data,
      getValue: (field?: string) =>
        this.data && field ? this.data[field] : this.value,
      node: this.node,
    };
  }

  init(params: Params<T>): void {
    this.updateParams(params);
    this.setGui();
  }

  destroy(): void {
    if (this.handleClick !== null && this.btnEl !== null) {
      this.btnEl.removeEventListener('click', this.handleClick);
    }
  }

  getGui(): HTMLElement {
    return this.btnEl!;
  }

  refresh(params: Params<T>): boolean {
    this.updateParams(params);
    const isAbbreviated = this.isAbbreviated?.(this.valueGetterParams) ?? false;
    this.value = this.transform(params.value, isAbbreviated);
    if (this.btnEl) {
      this.btnEl.innerHTML = this.value;
    }
    return true;
  }

  private setGui(): void {
    this.btnEl = this.document.createElement('button') as HTMLButtonElement;
    this.btnEl.classList.add('user-name-cell');
    this.handleClick = (event) => {
      if (this.click) {
        this.click({
          event,
          data: this.data,
        });
      }
    };
    const isAbbreviated = this.isAbbreviated?.(this.valueGetterParams) ?? false;
    this.btnEl.innerHTML = this.transform(this.value, isAbbreviated);
    this.btnEl.addEventListener('click', this.handleClick);
  }

  private updateParams(params: Params<T>): void {
    this.api = params.api;
    this.click = params.click;
    this.colDef = params.colDef;
    this.column = params.column;
    this.columnApi = params.columnApi;
    this.context = params.context;
    this.data = params.data;
    this.document = params.document;
    this.isAbbreviated = params.isAbbreviated;
    this.node = params.node;
    this.value = params.value;
  }

  private transform(value: string, isAbbreviated: boolean): string {
    if (isAbbreviated) {
      return value.replace(/^Model/i, '');
    }
    return value;
  }
}

Ok, phew. Let’s review the code above.

First, we define a new Params type that is a union of our NameCellRendererParams interface and the AG Grid provided ICellRendererParams. The generic type T is the provided type for the AG Grid row data, which we further provide to the ICellRendererParams interface. The second typescript generic is explicitly set to string as we expect that the value of the cell will always be a string.
We export the NameCellRenderer class whose generic type T extends our previously defined NameCellRendererData interface. This ensures that we have type safety between the row data provided to AG Grid and our cell renderer. As required, our class implements the ICellRendererComp interface from AG Grid.
We have a lot of properties that declared that will have references and values as necessary to pass to the isAbbreviated provided callback function.
Note that the click property is the provided callback function from the implementation that is invoked when the user clicks on the name.
Further, note that the handleClick property is an execution-bound function that we’ll use within the cell renderer class for adding and removing the event listener.
The valueGetterParams property accessor method returns a ValueGetterParams<T> object that is used by the implementation to determine if a name is abbreviated or not. We have decided to use this interface from AG Grid to keep a consistent API for our users (those developers using our cell renderer in their AG Grid implementations). This is important for API ergonomics.
The init(), getGui(), refresh(), and destroy() methods are all implemented according to the ICellRendererComp interface from AG Grid. These methods provide hooks to initialize the cell renderer, provide an HTML element to be appended to the DOM by AG Grid when rendering a cell, and more hooks for when the data is refreshed and when the cell is destroyed. It’s important that we use the destroy() lifecycle method to do any necessary cleanup, such as removing event listeners, to prevent memory leaks in our application.

Finally, here is an example implementation of the NameCellRenderer.

interface RowData {
  id: string;
  name: string;
}

export default function DashboardGrid () {
    const colDefs = [
      {
        colId: 'name',
      field: 'name',
        headerName: 'Name',
        cellRenderer: NameCellRenderer,
      cellRendererParams: {
        click: ({ data }) => {
          window.alert(`You clicked: ${data.name}`)
        },
        document,
        isAbbreviated: ({ data }) => {
          return data.name.length > 20;
        },
      } as NameCellRendererParams<RowData>
      }
    ] as ColDef<RowData>[];

    return (
    <AgGridReact
      colDefs={colDefs}
      rowData={rowData}
    />
    );
}

Summary

So In summary, we have learned how AG Grid renders a cell, and how we can provide data to a cell, optionally format a cell, and if necessary, customize the rendering of a cell.
The key takeaways are:

Use the valueGetter() callback function to fetch and/or mutate the value of a cell.
Use the valueFormatter() callback function to format a cell’s value.
If necessary, provide a cell renderer to customize the HTML of a cell.
Cell renderers can also be interactive, invoke callback functions, and more.
It’s important to remove event listeners when a cell is destroyed.
Design an API that is ergonomic.
Create value getters, value formatters, and cell renderers that are type safe.

20 Questions on Product Validation

Brian Love — Wed, 22 Jun 2022 17:04:26 +0000

"The biggest men and women with the biggest ideas can be shot down by the smallest men and women with the smallest minds.

Think big anyway.”

The first step is thinking big. The second step is validation. So, how do we validate a digital product?

Let’s answer this question with more questions - specifically, 20 more questions.

What is product validation?

Product validation is a systematic approach to measuring a concept with potential customers. This is the moment of truth - if you build it, will they come?

Product validation does not ensure the success of a business or product. Far from it. It only enables you to have insight into the validity of a concept. It’s very likely that your concept is not valid, or, perhaps that your concept needs to pivot.

Why is product validation necessary?

Product validation is necessary to understand your target customer. Without product validation, a startup will waste time - and money.

When should I validate?

As early as you can. A drawing on a napkin will do - starting validation of a product does not require sophisticated wireframes, user requirements, high-fidelity mockups, or an impressive presentations. Presenting concepts that invoke meaningful feedback is the key.

How often should I validate?

Product validation should be an ongoing part of your design process that occurs after each iteration of a prototype.

At LiveLoveApp, we use Google’s approach to design sprints that is a sequence of the following steps:

Understand
Define
Sketch
Decide
Prototype
Validate

There it is - after each iteration of a prototype when building a product we always want to validate the concept with real users.

How do I find early adopters?

Not everyone is your target customer. I mean, it’s likely not your mum - she’s likely going validate every concept. That’s not very useful.

Early adopters are interested in providing influence on the development of an early technology in return for prestige, gaining a competitive advantage, or having lifetime access to a product. Early adopters may be within the reach of your network, but they are likely one or two degrees removed. Strategies such as pre-release, invite-only access, and possibly, lifetime access can lure early adopters to your product. An often overlooked but valuable strategy for getting the attention of your early adopters is through direct communication channels for your industry and your target customers such as online groups, forums, in-person meetups, and social media.

What feedback is useful?

Useful feedback should measure both the satisfaction of the user and the result of a user completing a specific task using your product.

Gathering holistic feedback that is vague and filled with general platitudes is not useful.

What if they’re wrong?

All user feedback should be noted, but not all user feedback is valuable. If all of your user feedback is perceived as wrong, well then, you’re probably wrong. It’s important to dig deeper if you believe validation feedback is incorrect. This may be an opportunity to identify a pivot.

How do I gather feedback?

Gather feedback through a usability study and a cognitive walkthrough. A usability study focuses on the user interface of your product to determine if the prototype’s user interface is acceptable or needs to be improved. A cognitive walkthrough evaluates the product’s ability to solve a specific task. It’s important to instruct users that you are not testing them, rather, you are testing the product. Finally, coach your users to think aloud.

Should I use unmoderated tools?

Moderated usability studies are those in which a person that is familiar with the product facilitates. Moderated usability studies and cognitive walk-throughs provide the most effective feedback for validation. On the other hand, Unmoderated usability studies do not have a person present for facilitation. Similarly, unmoderated tools can measure and monitor product use, providing insight into how a user discovers and interacts with your product without guidance.

Do I need a prototype?

Yes. However, your prototype does not necessarily need to be high fidelity. It is useful to gather feedback through low-fi prototypes before iterating toward high-fi prototypes.

Do I need an MVP?

No. A minimum viable product (MVP) should only be developed after prototype iteration. Only upon completion - and validation - of a prototype should an MVP be developed.

An MVP is yet another opportunity to validate and gather feedback. The breakeven of the MVP development expense should ideally equal the value of the feedback and validation.

Do I need to generate revenue?

The goal of the product is to generate revenue (though, not necessarily as may be the case for a public works product, government product, not-for-profit products, etc). However, the goal of product validation is not to generate revenue.

Should I presell?

Using a pre-selling strategy for product validation can provide both feedback and revenue. Preselling can also build community and urgency. The risk is that things can go wrong, so it’s important to clearly communicate a refund policy.

What about LTDs?

A lifetime deal (LTD) provides an opportunity to attract early adopters with the ongoing expense of providing access to your product.

Do I reveal my product roadmap?

Revealing a product roadmap to early adopters provides validation of feature expansions. However, this could also provide existing competitors and would-be competitors with insight into your future features. It is important to consider the size of the moat around your product and to use legal non-disclosure agreements.

Should I have a public beta?

A public beta provides further validation of your product through metrics and can build community and urgency. A public beta can be used effectively in conjunction with preselling. The risks are negative reviews or early adopters vomiting.

Should I raise capital from early adopters?

Raising capital from early adopters enables you to retain equity before potential liquidation during capital raising events.

How do I identify potential pivots?

Product validation may reveal opportunities for a pivot of your product. When gathering feedback it is important to note problems that a user identifies with the user interface and how they use the product, but also problems that exist that the product does not solve. Those problems may be beyond the scope of your existing product. As with all products, validating a potential pivot is critical.

What are the risks with product validation?

The goal of product validation is to reduce risk, however, there are some risks associated with product validation. Preselling can introduce risk, flopped beta launches can be risky, and leaks to existing and would-be competitors could risk your (hopeful) blue ocean. Mitigate these risks through clear communication, striving for excellence, and legal containment.

Angular 14 Standalone Components

Brian Love — Fri, 17 Jun 2022 17:50:59 +0000

Angular version 14 is a feature-packed release that brings new APIs, functionality, and a developer experience. Angular version 14 is arguably the biggest release since version 9 when Angular’s newest compilation and rendering engine (called Ivy) was released.

This article is the first in a series that will cover the key features and takeaways that I believe angular developers and engineering managers should know about Angular version 14. First, we’ll start with the hottest new topic called standalone components. Then, we’ll dive into typed forms, what they are, and what this means for you and your organization. We’ll talk about version dependency updates, improvements to the Angular Language Service, new configurations to improve testing at runtime, and a small compiler update.

Let’s dive into Angular’s new developer preview of standalone components!

Angular 14 Playground on Stackblitz

Real quick - before we dive into the details - I want to mention that I have an Angular 14 Playground for you on Stackblitz. Much of the example code below is referenced from this small project. Check it out and feel free to fork it!

https://stackblitz.com/edit/angular-v14-playground?file=src%2Fmain.ts,src%2Fabout.component.ts

What is a standalone component?

Prior to version 14, all components had to be declared as part of the declarations array in an NgModule. NgModules are a critical building piece to solve architectural challenges in Angular, namely importing other modules in your codebase or importing other modules that are published as part of a library (using the Angular Package Format. NgModules also provide a mechanism for wiring up and configuring dependency injection. We’ll discuss both of these in more detail below.

Standalone components enable Angular developers to build applications without using the NgModule based approach.

💡 In this article, I will often refer to Angular’s NgModule simply as a “module”. This is in an effort to improve readability and is not meant to be confused with ECMAScript modules.

The immediate question is what about applications built today with modules? Will modules be supported in the future?

The answer is a resounding yes. Angular applications, and libraries, that are built with modules will continue to be supported. Flatly stated, modules are not going anywhere.

Further, Angular’s new standalone component architecture is fully compatible with the existing module-based architecture. You can continue to use modules where necessary and/or preferred, and you can start using standalone components alongside them. Based on your team and organization’s architectural style, you can start adopting standalone components, or you can continue to build Angular applications using modules as you have been doing for the past 6 years. This continues on the Angular Team’s promise to not leave anyone behind with breaking changes.

Will standalone components replace modules as the de facto style?

At the time of this writing, as Angular version 14 is just now being released, the answer to this question is unknown. This will likely depend on community adoption and tooling. Further, the current documentation, getting started journey, and style guide do not teach standalone components over the module-based approach.

Why are standalone components in “developer preview”?

Standalone components are being released in version 14 as a developer preview. This means that the LTS policy for the APIs does not apply to standalone components. This is a good thing! As the community adopts this new architectural pattern we will all learn from each other what works well, what is cumbersome, and, potentially, what are the edge cases where this architectural pattern breaks. This learning enables the framework to innovate at a fast pace. It also means that the APIs, while public, may change in future minor releases.

Getting Started with standalone Components

To use standalone components, Angular has introduced a new standalone property in the component metadata. The property is false by default.

Here is a quick example of a standalone component:

import { Component, Input } from '@angular/core';

@Component({
  standalone: true,
  selector: 'app-root',
  template: `
    <ng-content></ng-content>, {{ name }}.
  `,
  styles: [``],
})
export class NameComponent {
  @Input() name = '';
}

The code example above is like any Angular component except that we have set the standalone property to true. This instructs the compiler to treat this component as standalone, and further, this prevents us from including the component in the declarations array of a module.

Standalone components must declare their own dependencies including child standalone components. For example, to use the <app-name> component in another standalone component, I must import the component:

@Component({
  selector: 'my-app',
  standalone: true,
  template: `
    <app-name [name]="name">Hi</app-name>
  `,
  imports: [CommonModule, NameComponent],
})
export class AppComponent {
  name = 'Brian Love';
}

In the code example above note that I have included our NameComponent in the imports array in the component metadata. This instructs the compiler that this component is a dependency of the AppComponent, which is also a standalone component.

What about existing `NgModule` uses?

As stated previously, standalone components are fully compatible with existing codebases that use the NgModule pattern. If a standalone component uses a directive, component, or pipe that is exported from a module then we include the module in the imports array in the standalone component metadata to import the module. All publicly exported members of the module are now available for use in the standalone component.

Let’s expand our current example application to use Angular Material. To do so, we’ll need to import the necessary modules:

@Component({
  selector: 'app-root',
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
  imports: [
    CommonModule,
    MatIconModule,
    MatListModule,
    MatSidenavModule,
    MatToolbarModule,
    RouterModule,
  ],
  template: `
    <mat-toolbar class="toolbar">
      <button mat-icon-button aria-label="Toggle menu" (click)="toggleMatSidenav()">
        <mat-icon>menu</mat-icon>
      </button>
      <span>Angular v14 Playground</span>
    </mat-toolbar>
    <mat-sidenav-container class="container">
      <mat-sidenav [(opened)]="matSidenavOpened" fixedTopGap="64" fixedInViewport>
        <mat-nav-list>
          <a mat-list-item routerLink="/">Home</a>
          <a mat-list-item routerLink="/about">About</a>
          <a mat-list-item href="https://liveloveapp.com" target="_blank">Learn More about LiveLoveApp</a>
        </mat-nav-list>
      </mat-sidenav>
      <mat-sidenav-content class="content">
        <main>
          <router-outlet></router-outlet>
        </main>
      </mat-sidenav-content>
    </mat-sidenav-container>
  `
})
export class AppComponent {
  matSidenavOpened = false;
  name = 'Brian Love';

  toggleMatSidenav(): void {
    this.matSidenavOpened = !this.matSidenavOpened;
  }
}

Let’s review the code above:

First, you’ll note that the AppComponent has the standalone property set to true in the component metadata.
I went ahead and update the change detection strategy, really just to test out how this works with standalone components, and thankfully, it works as expected.
Note the imports array. I’ve imported the necessary material modules that I need for the component. I’ve also imported the RouterModule since my component’s template includes the <router-outlet> custom element.
For the sake of brevity, I skipped the styles (but you can check out the full Angular v14 Playground demo on Stackblitz).

Dependency Injection with standalone Components

Before we dive into a few of the important updates in Angular v14 to support standalone components, let me reiterate a few things.

First, the developer experience for module-based Angular applications using dependency injection has no breaking changes, and for the most part, has not changed. You can continue to use the injector, injection tokens, providers, and the @Injectable() decorator just as you have prior to Angular version 14.

Second, the dependency injector hierarchy is still very similar, with a few exceptions that we’ll cover shortly.

Module type injectors are available using the providers array within the NgModule metadata as well as by using the providedIn decorator. Specifying the root value for the providedIn decorator will register the class at the root level that is available throughout your Angular application.

Here is a quick example of module type injectors that you are likely familiar with:

// Module type injector using NgModule metadata
@NgModule({
  providers: [
    UserService,
    {
      provide: MAT_FORM_FIELD_DEFAULT_OPTIONS,
      useValue: { appearance: 'outline' },
    },
  ]
})
export class AppModule {}

// Module type injector using providedIn property
@Injectable({
  providedIn: 'root'
})
export class UserService {}

Node type injectors enable us to limit the provider scope through the use of the providers array for a directive or component. One common use case for limit provider scope is when you are using NgRx’s Component Store:

// node type injector
@Component({
  providers: [GridComponentStore]
})
export class GridComponent {}

Now, let’s learn some of the new terminology and features introduced in Angular version 14.

First, Angular 14 adds a new viewProviders property to the @Component() metadata that enables us to further limit the provider scope to children of the existing component.

// node type injector usin `viewProviders`
@Component({
  selector: 'app-name',
  template: `
    Hello, {{ user$ | async | greet }}
  `
})
export class NameComponent {
  user$ = this.userService.user$;

  constructor(private readonly userService: UserService) {}
}

@Component({
  viewProviders: [UserService],
  template: `
    <app-name></app-name>
  `
})
export class ToolbarComponent {}

Next, Angular 14 introduces a new term called “Environment Injectors”. Environment injectors cover the following scenarios:

Module type injectors. As discussed above, this includes providers declared in a module as well as those that use the providedIn property for the @Injectable() metadata.
Providers that are declared when the application is bootstrapped.
Providers that are declared within the providers array for a Route.

Let’s look at an example of declaring providers when an application is bootstrapped. Common use cases include providing the BrowserAnimationsModule, registering root-level routes using the RouterModule.forRoot() static method, and registering NgRx’s global store using the StoreModule.forRoot() static method.

bootstrapApplication(AppComponent, {
  providers: [
    importProvidersFrom([
      BrowserAnimationsModule,
      RouterModule.forRoot(routes)
    ]),
  ],
});

In the example above we are also introducing the importProvidersFrom() function. This utility function collects all providers from one or more sources that are either a standalone component or an NgModule.

Also introduced in Angular 14, we can declare an array of providers within a Route configuration that will create an Environment Injector at the route level. This enables the providers to be used within all components within the route, and all child routes.

const routes = [
  {
    path: 'users',
    loadChildren: () =>
      import('./users.module').then(({ UsersModule }) => UsersModule),
    providers: [
            UserService,
        {
          provide: MAT_FORM_FIELD_DEFAULT_OPTIONS,
          useValue: { appearance: 'outline' },
        },
    ]
  },
  { path: '**', redirectTo: '' },
] as Routes;

Finally, Angular 14 introduces an additional injector type that is termed a “Standalone Injector”. No, the poor injector is not standing alone on the playground without any friends. The Standalone Injector is a child of the root environment injector and is responsible for isolating all providers for standalone components.

Routing with standalone Components

Angular 14 introduces an expanded API for routing with standalone components, including a feature that enables us to very easily lazy load a standalone component. If you are familiar with the router’s loadChildren configuration property that enables lazy-loading modules, then you will be very comfortable using the new loadComponent property.

const routes = [
  {
    path: 'about',
    loadComponent: () =>
      import('./about.component').then(({ AboutComponent }) => AboutComponent),
  }
] as Routes;

In the code example above we are lazy loading a single standalone component at runtime with a simple configuration within the route.

Angular 14 also introduces a new feature that enables us to lazy load routes without the need to wrap them up in an NgModule using the RouterModule.forChild() static method.

const routes = [
  {
    path: 'admin',
    loadChildren: () =>
      import('./admin/routes').then(({ routes }) => routes),
  }
] as Routes;

Note, that in order to use this new feature, all routes must use standalone components. This feature is not compatible with existing non-standalone components defined within the routes.

Conclusion

In conclusion, Angular version 14 shipped a new developer preview of the standalone components API. This API enables Angular developers to build applications without the use of the NgModule architecture. The primary goals of standalone components are to simplify the API, improve developer ergonomics and velocity, and to enable future innovation in the Angular ecosystem. Standalone components do introduce some changes to the dependency injection system and the routing story. Finally, we should note that this new feature is backward compatible with existing Angular code that uses the NgModule architecture, and that this is a developer preview - meaning that the API is not finalized and could have breaking changes in the future.