Forem: Y.Arakawa

Structuring Reusable Search Screens in Razor Pages

Y.Arakawa — Sun, 05 Apr 2026 03:19:39 +0000

Search screens look simple when you only have one or two of them.

That was not the situation I was dealing with.

I had many business screens with the same basic shape: a few search inputs, paging, sorting, and a table of results. The problem was not that any single screen was hard to build. The problem was that each new screen repeated the same query-building work in a slightly different way, and small changes started spreading across too many PageModel classes.

So the reason I changed the structure was straightforward: I wanted each screen to describe its own search conditions without re-implementing the same filtering and paging mechanics every time.

What worked better for me was to keep the search input on the PageModel, map those properties to entity fields with attributes, and let shared infrastructure build the EF Core query.

This is not a universal solution for every kind of search UI. It fits CRUD-heavy business screens where GET-based filtering, paging, and predictable extension matter more than highly custom search behavior.

The Shape I Wanted

The screen itself stays ordinary.

It is still a GET form with a results table.

@page
@model UsersModel

<form method="get">
    <div>
        <label asp-for="Name"></label>
        <input asp-for="Name" />
    </div>

    <div>
        <label asp-for="Phone"></label>
        <input asp-for="Phone" />
    </div>

    <button type="submit">Search</button>
</form>

<table>
    <!-- result rows -->
</table>

The important part is not the Razor markup. The important part is that search state stays in the query string, so reload, sharing, and debugging remain simple.

On the server side, I wanted the screen model to declare only the fields it cares about.

using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.RazorPages;

[BindProperties(SupportsGet = true)]
public abstract class SearchPageModel<TEntity> : PageModel where TEntity : BaseEntity
{
    protected readonly IRepository<TEntity> Repository;

    protected SearchPageModel(IRepository<TEntity> repository)
    {
        Repository = repository;
    }

    public int Skip { get; set; }
    public int Take { get; set; } = 20;
    public string? Order { get; set; }

    public PagedResult<TEntity>? Results { get; protected set; }

    public virtual async Task OnGetAsync()
    {
        var options = QueryOptionsBuilder.Build<TEntity>(this);
        Results = await Repository.QueryAsync(options);
    }
}

public sealed class UsersModel : SearchPageModel<User>
{
    public UsersModel(IRepository<User> repository) : base(repository)
    {
    }

    [Filter(FilterComparison.Contains, nameof(User.Name))]
    public string? Name { get; set; }

    [Filter(FilterComparison.Contains, nameof(User.Phone))]
    public string? Phone { get; set; }
}

That is the boundary I cared about.

The screen declares search intent.
Shared code handles the repetitive mechanics.

Moving Query Rules Out of the Screen

The small piece that made this scale better was a simple mapping attribute.

[AttributeUsage(AttributeTargets.Property, Inherited = true)]
public sealed class FilterAttribute : Attribute
{
    public FilterAttribute(FilterComparison comparison = FilterComparison.Equal, string? entityFieldName = null)
    {
        Comparison = comparison;
        EntityFieldName = entityFieldName;
    }

    public FilterComparison Comparison { get; }
    public string? EntityFieldName { get; }
}

public enum FilterComparison
{
    Equal,
    Contains,
    StartsWith
}

Then shared infrastructure reads those properties and turns them into query options.

using System.Linq.Expressions;
using System.Reflection;

public static class QueryOptionsBuilder
{
    public static QueryOptions<T> Build<T>(object conditions) where T : BaseEntity
    {
        var filters = new List<Expression<Func<T, bool>>>();

        foreach (var property in conditions.GetType().GetProperties(BindingFlags.Public | BindingFlags.Instance))
        {
            var filter = property.GetCustomAttribute<FilterAttribute>();
            var value = property.GetValue(conditions) as string;

            if (filter is null || string.IsNullOrWhiteSpace(value))
            {
                continue;
            }

            var entityFieldName = filter.EntityFieldName ?? property.Name;
            var parameter = Expression.Parameter(typeof(T), "x");
            var member = Expression.Property(parameter, entityFieldName);
            var contains = typeof(string).GetMethod(nameof(string.Contains), new[] { typeof(string) })!;
            var body = Expression.Call(member, contains, Expression.Constant(value.Trim()));

            filters.Add(Expression.Lambda<Func<T, bool>>(body, parameter));
        }

        // In a real implementation, sorting and paging would typically come from the request (e.g., UI input).
        // Hard-coded here for simplicity since they are not the focus of this article. 
        return new QueryOptions<T>(filters, orderBy: "Name ASC", skip: 0, take: 20);
    }
}

This example is intentionally simplified, but the design point is the same:
the PageModel should describe search fields, not rebuild query assembly logic over and over.

Why This Worked Better

The main benefit was not fewer lines of code by itself.

It was that the extension path became predictable.

If a screen needed one more condition, I added one property and one attribute.
If I wanted to adjust shared search behavior, I changed the infrastructure once.

Using nameof also removed a lot of fragile string matching between screen fields and entity fields, which matters more than it first appears when CRUD screens start multiplying.

This structure also kept the screens naturally URL-driven.
For this kind of business search screen, that is usually what I want.

Trade-Offs

This approach is useful when the search model is mostly declarative.

If a screen has deeply custom filtering rules, highly dynamic query composition, or search behavior that no longer maps cleanly to a property-per-condition model, I would not force it into this shape.

The point is not to abstract every search screen.
The point is to stop repeating the same mechanical work where the screens are actually similar.

Closing

What I wanted was simple: each screen should describe what it searches, and shared infrastructure should handle how the query gets assembled.

That boundary made Razor Pages search screens easier to extend without turning each PageModel into a copy of the previous one.

This kind of structural thinking is also part of what led me to build Cotomy. If you want the longer architectural background behind how I structure business-oriented web screens, I’ve been writing more of that here: https://blog.cotomy.net/

How I Stopped UI State Drift with a DOM Boundary Approach

Y.Arakawa — Fri, 03 Apr 2026 13:11:08 +0000

One of the most frustrating UI failures is not a dramatic JavaScript bug. It is when CSS stops feeling explainable. You change one screen and another screen shifts. The same HTML looks different depending on where it appears. After a while, it becomes difficult to tell which style is actually responsible for what you are seeing.

The Real Problem Was Separation

At first, this looks like a CSS problem. In practice, it is usually a structure problem.

HTML defines the shape of the UI. CSS often lives somewhere else entirely. DOM behavior is then added from another place again. Each part may look reasonable on its own, but the unit they are supposed to describe no longer exists in one place.

That is where drift starts. The UI is assembled from related parts that are managed as if they were unrelated.

When a UI Unit Does Not Exist

This was the point that kept bothering me in real screens.

HTML alone does not fully describe the element as it actually behaves. CSS alone does not tell you which structural unit it truly belongs to. DOM code can modify the same area without carrying either the styling context or the original structural intent with it.

So the issue was not only that CSS was global, or that DOM code was scattered. The issue was that there was no clear UI unit that held those responsibilities together.

Without that unit, small fixes accumulate in the gaps between files. A selector is adjusted in one place. A style rule is added in another. A DOM patch appears elsewhere. Each change can be locally reasonable, but the screen as a whole becomes harder to understand.

The Turning Point

One thing that pushed my thinking forward was working with Razor Pages.

What mattered most was the cshtml and cshtml.css pairing. That model let me define CSS alongside the page and have it automatically scoped so it only applied inside that cshtml. The impact range was narrow by default, which meant I could implement styles without constantly worrying that they would damage some other part of the system.

That did not solve frontend structure by itself, but it made one point much clearer: related responsibilities become easier to manage when they stay attached to the unit they actually belong to.

That led me to a frontend question I had not framed clearly enough before:

what if HTML and CSS should also stay attached to a meaningful element boundary?

The Boundary Idea

The important shift was to stop thinking only in terms of DOM operations and start thinking in terms of element ownership.

Instead of treating HTML as markup, CSS as a separate styling concern, and DOM code as a loose behavior layer, I started thinking of them as one operational unit. One boundary should own one structural root, one local styling context, and one place where DOM behavior belongs. Because that boundary becomes the only place where structure, style, and behavior can meet, changes stop leaking across unrelated parts of the UI.

That does not mean every screen must become a component framework. It means the UI should have a unit small enough to own its own structure.

A Minimal Shape

The idea is easier to explain if you imagine implementing a small unit called ElementBoundary:

const profileCard = new ElementBoundary(
  /* html */ `
    <section>
      <h2 class="title">Profile</h2>
      <p class="value">Active</p>
    </section>
  `,
  /* css */ `
    [root] {
      padding: 12px;
      border: 1px solid #d0d7de;
    }

    [root] .title {
      font-size: 14px;
      margin: 0 0 8px;
    }
  `
);

const screen = ElementBoundary.first("#screen"); // get the screen boundary instead of accessing raw DOM
screen.append(profileCard);

The point here is not the constructor signature. The point is that one element unit owns both its HTML and its CSS, and that the existing screen container is treated through the same kind of boundary instead of dropping back to raw DOM access.

Here [root] is just a placeholder for the boundary's own root element. When the boundary is created, that placeholder can be rewritten to a boundary-specific selector automatically, so the CSS applies only inside that unit and does not leak into other parts of the screen.

This is also not the same point as Shadow DOM. The goal here is to keep working with the ordinary DOM flow and the same basic screen-building steps, while still gaining a narrower styling boundary that can be extended as the UI grows.

It also keeps creation, lookup, and placement within the same model, instead of treating those steps as unrelated DOM operations.

That is what I mean by a boundary: a unit where structure, style, and behavior are owned together, so changes no longer leak across unrelated parts of the UI.

Why This Changed Things

Once I started thinking this way, several UI problems became easier to control.

CSS became more local because it was tied to an element root instead of being treated as an unrelated global layer. DOM behavior became easier to place because it belonged to a specific unit instead of floating across the page. And the UI itself became easier to reason about because both existing areas and newly created areas could be handled through the same structural meaning.

Instead of asking which selector was responsible, I could ask which element owned the change.

The benefit was not just cleaner code. It was that the screen started having understandable structural ownership again.

What This Is Not

This is not a claim that every project should invent its own wrapper. It is also not a claim that global CSS should never exist.

The main point is smaller than that. If HTML, CSS, and DOM behavior are allowed to drift too far apart, the UI loses a meaningful unit of responsibility. Once that happens, fixing visible issues becomes much more reactive than structural.

Where This Led

I eventually refined this way of thinking into something I could publish as a real tool, and released it as Cotomy.

I’ve written more detailed notes about these failure patterns and their background here: https://blog.cotomy.net/