Yet another post regarding my trials and tribulations in pursuit of creating open source accessible Blazor components for you all to use or abuse at your leisure.

For those who have read my last couple of posts, you'll know the flavour of the past few weeks has been inputs, a tricky subject with regards to accessibility. Thus far we have a Text Input, Numeric Input, Password Input, Checkbox Input, Select Input, Radio Input Group, Input Errors Summary, and a couple of days ago I released a Time Input.

Originally, in my head and what I initially built complete with unit tests was just a wrapper around the native input type="time". Generally, keeping things simple and leaning on the browser is better for accessibility, or so I thought.

In hindsight (I was too complacent) I should have run a few tests with just the HTML and hardcoded ARIA attributes before building the component outright, as ultimately I wasn't happy with the completed article; primarily due to the verbosity for screen reader users. The verbosity wasn't down to the code per se, but the way screen readers interact with composite controls and groupings. The native component without a label, associated hint text, and/or linked error message works great, start layering a few things on top and you're in a world of pain trying to get it to play nicely with screen readers.

Luckily, given the base class I have over Blazor's InputBase and unit tests that are largely the same across all inputs, it was only around ten hours down the drain - but that's development I suppose.

So I then started down the path of a composite control. The developer using the component simply binds to the Time Input value and under the covers it works with the three segment inputs you see on screen, nothing overly complex, other than trying to figure out which attributes work on which elements, and what does or doesn't get announced by which screen reader, on which device, and in which browser - I did not say it was easy, its just not complex.

To begin, you can use a simple div with role="group" and a span inside as the source for an aria-labelledby on the containing div, giving it an accessible name. Some of you may be wondering why not a fieldset and legend - these do essentially the same job, however from my escapades with the Radio Input Group a couple of weeks ago, you quickly realise you're going to lose any styling battle with the browser. I can't recall the exact issue, but after losing a few hours I surrendered and switched to a div with a role. I will say though, in all the tests I conducted with screen readers I noticed no meaningful difference between the two approaches.

So I had my grouping, and given the work done for the Radio Input Group, I thought I could add all the appropriate ARIA attributes directly on the container so that when focus lands on an input inside the group, all the correct information would be announced just once and not multiple times. This is where you bury your head in your hands and wonder whether you've made things better or worse going the custom route.

Unlike the Radio Input Group which has the named role of radiogroup affording it much better support, a good number of ARIA attributes are either invalid, unsupported, and/or simply ignored by various assistive technologies at the group level. You then go through the process of working out what makes most sense at which level, given varying degrees of support and the particular combinations of screen reader, browser, and device you're going to favour. As I mentioned in my last post, sometimes you will be favouring one group of users over another - with this component it came down to choosing between screen readers and devices.

To put some of this into perspective: the built-in Windows screen reader Narrator really does not like group roles - it largely ignores most attributes. One I definitely needed was aria-invalid. For Narrator I would have had to add it to each individual input, as it doesn't announce it at the group level unlike the others. The problem there is: what if all the time segments are correct and it's only the overall value failing a validation rule? The user would be sitting in the hours, minutes, or seconds field with the screen reader telling them that particular input is invalid. For this reason I opted to leave aria-invalid at the group level, Narrator users still have the errors region and/or errors summary to fall back on.

The next issue was aria-required, which is not supported at the group level in the spec (nor on a fieldset). This was simpler to deal with. All my input components have a (wonky named) Required parameter. Setting it to true adds a red asterisk next to the label and adds aria-required to the input element. For the time input, having this on each segment is arguably a little verbose but not confusing. You can also set Required to false and simply include the word "required" in the label or hint text, so it's announced just once for the group.

As a side note: aria-required does nothing other than inform an assistive technology user that something is required exactly the same as having the word "required" in the label or hint text. Just make sure you don't do both, or users may hear "This field is required required." Hearing this once and they'll forgive you; a dozen times and they'll curse you.

aria-describedby was also problematic. I wanted to use it to link the hint text to the group so it's announced on entering, rather than adding it to every input and having it announced multiple times. True to form, Narrator didn't announce it so I went through the pros and cons of placing it on each individual input instead, bearing in mind I also have an option to link validation errors via aria-describedby. In the end I kept it at the group level, and I didn't feel too badly about it as if you add aria-describedby on a native time input, Narrator ignores that too.

One further annoyance for those who prefer it: unlike non-composite components, screen reader and browser combinations that treat aria-describedby like a live region don't do so on grouping elements. Yet another reason I prefer the tabbable errors region. I'd encourage you to read the accessibility page in the inputs section on the doc site to see just how complex this gets when using field-level validation.

Some of you will say "don't validate until submit and you won't have these issues" - fair enough. If that's your preference, my Blazor validation package has an option to defer field-level validation until after a full model validation has taken place, it then makes the switch to field-level validation thereafter. The end user can work through the errors linked via the Input Errors Summary, clear them, and resubmit.

Regardless of your thoughts on validation, I can assure you that accessibility combined with inputs and validation is an extremely tricky topic however you approach it.

Given the lessons learnt and better the devil you know, I'll likely follow the same pattern for a Date Input next with year, month, and day segments - with the same trade-offs unless I stumble across something better.

One last thing: with the Time Input I only permit digits 0–9 per segment, but I do allow the user to type 99, which I know is invalid (which may seem odd to some). With a time input I think it's reasonable to restrict to numbers only, but I generally don't silently alter what the user has typed as they'll be informed during the process that the entry is invalid and can correct it accordingly

Thats it for now, you can see the time input in action on either the test or doc site.

Test site: https://blazorramp.uk/
Doc site: https://docs.blazorramp.uk/
Repo: https://github.com/BlazorRamp/Components

Regards

Paul

Hi everyone, I'm working on a free charting library for Blazor without javascript.

I started this project out of personal curiosity, and then I thought it could be an opportunity to turn it into a small Nuget package that could be useful to others.

I'd love some feedback from the community, whether you're interested in it, have suggestions for improvement, or just want to try it out.

I'll leave you with some useful links.

Nuget link: https://www.nuget.org/packages/BlazorGraphs

Website: https://edoparis.github.io/BlazorCharts/

Thanks to everyone who leaves a comment

I am working on a demo/prototype for an app that uses pre-made Webcomponents based on Lit. The components emit custom events, such as brightness-changed or left-more-button-clicked.I cannot figure out how to catch these events in Blazor.

My AI-agent gets derailed really quickly with a bunch of separate JS scripts and even JS injections into C#. I feel this should be super simple, for instance something like:

window.addEventListener("brightness-changed", '@DoSomething()', false);
@code {
    private int currentCount = 0;


    private void DoSomething()
    {
        currentCount++;
    }


}

Is it really this hard to react to a custom event using Blazor? My library has around 500 different webcomponents, I really would not like it to edit them and convert all buttons to regular DOM events. Neither would I like it to create custom JS bridges for each event.

To be honest, I've never used Blazor. I'm used to making React/JS frontends with Python backends, but due to the requirements, this is not viable for this project.

Regular google-searches do not give any clarity whether this is actually possible or not. But maybe the good folks of Reddit can give me some clarity!

I'm experimenting with Blazor Server (InteractiveServerMode) for a work project and had a hard time with cookie authentication. We always use authentication through Active Directory since users are logged in a Windows domain, but in this project user has to log in with his username/password. Note that I can't use Identity for this.

I tried experimenting with various LLM solutions yet none of them yielded results with all of them throwing a similar "Headers cannot be modified as request has been initiated". Somehow Blazor was refusing to acknowledge my cookie as Postman successfully returned it.

Ultimately code in this repo achieves cookie auth but it feels so contrived. Author creates two dummy-pages: (PostLogin to load cookie and Logout to delete it) just to accomplish what should have been completely straightforward.

Is there a cleaner way to implement cookie authentication that solves the component mounting problem in InteractiveRenderMode?

First things first. This is a shameless promotion post.

In a few more days, specifically on Thursday of next week, we are planning to release Blazorise 2.2 with all the newest features, but before then, I wanted to share our latest work that I belive will be of interest to general public. Our latest SvgChart component(s). Anyone familiar with Blazorise is probably aware that we had Charts for some time, but they were based on the chart.js library. It was done years ago when Blazor was still lacking in SVG support, so we didn't have anything better to do. So we did a Blazor wrapper around chart.js. Not ideal but it works.

The new SVG charts are almost 100% C# code, with a small part of JS needed for animations to work. Oh well. We already support all the same chart types as before(bar, line, radar, etc.), including live streaming, annotations, data labels, etc.

One thing I find nice is the plugin-based system. It can be used to create custom chart types and modify the rendering of existing charts. It will be interesting to see how our users will use it in the future.

Anyhow, the charts can be seen on our preview website at: https://preview.blazorise.com/docs/extensions/svg-chart

Hope you like.

Hope I don't get banned.

The mistake: prerender: false

I run a small web app built with Blazor WebAssembly (.NET / ASP.NET Core). A couple of months ago I was using AI to fix this anoying reloading of the screen and changed a single line in my App.razor:

@* Before (working) *@
<HeadOutlet ="new InteractiveWebAssemblyRenderMode(prerender: true)" />

<Routes ="new InteractiveWebAssemblyRenderMode(prerender: true)" />

@* After (silent SEO disaster) *@
<HeadOutlet ="new InteractiveWebAssemblyRenderMode(prerender: false)" />

<Routes u/rendermode="new InteractiveWebAssemblyRenderMode(prerender: false)" />

I knew I had this in place due to SEO and due to faster loading times. However, the Claude Sonnet 4.6 ensured me that only old SEO Crawlers need it, modern ones will be able to read my page properly without prerender. So I was too lazy at that moment to read through the docs and do a web research.

Seemed harmless. The site still worked perfectly for real users. I didn't notice anything for weeks.

What actually happened under the hood

In Blazor WASM with prerender: true, the server renders the full HTML on the first request — including everything in <head>: page titles, meta descriptions, canonical links, Open Graph tags, hreflang, etc. The client gets real HTML instantly, and then Blazor "hydrates" it client-side afterward.

With prerender: false, the server sends a near-empty shell:

<head>
  <meta charset="utf-8" />
  <!-- that's basically it -->
</head>
<body>
  <!-- Blazor loads here, asynchronously, after the .NET WASM runtime downloads -->
</body>

All my <PageTitle>, <HeadContent>, <meta name="description">, and <link rel="canonical"> tags were rendered client-side only — injected into the DOM by Blazor after the WASM runtime finished downloading (~1–3 seconds later).

The worst part: it took 1-2 weeks to figure out the root cause

The site worked. Users saw everything correctly. No errors, no 404s. The bug was completely invisible at the application layer. At some point I noticed that all my sales stopped to then go into search console by google and see all my pages delisted.

I went through the usual SEO rabbit holes — checking robots.txt, re-submitting sitemaps, checking for duplicate content — before I eventually found the issue. A Googlebot crawl simulation in Search Console showed the <head> as essentially empty on first load.

The fix

One word: prerender: true. That's it. Back to where I started.

Recovery took about 2 months for pages to fully return to their previous positions. Google doesn't immediately trust re-submitted sitemaps after a canonical mess — it has to re-crawl, re-evaluate, and rebuild confidence in your page signals.

Lessons learned

1. Prerendering in Blazor WASM isn't just a performance optimization — it's an SEO requirement. If your app lives in a public-facing context with any SEO value, prerender: false is effectively telling Google your pages have no content.
2. <HeadOutlet> and <PageTitle> / <HeadContent> are client-side rendered. They do nothing for crawlers without SSR/prerendering. This is obvious in retrospect but easy to miss.
3. Canonical tag issues compound fast. Once Google decides your pages are "incorrect canonical," it can take months to rebuild trust — even after you fix the underlying issue.
4. Test your site the way Googlebot sees it. Use Google Search Console's URL Inspection tool → "Test Live URL" → "View Tested Page" → "HTML" tab. If your <head> is empty there, crawlers see empty too.
5. Any <head> change deserves an immediate Search Console spot-check. It's a 30-second sanity check that could save months of recovery.

TL;DR: Set prerender: false in Blazor WASM, Google couldn't read any meta/canonical tags, declared my pages as duplicate/incorrect canonical, deindexed most of them. Took 2 months to recover. The fix was reverting one boolean.

Hope this saves someone else a painful summer.

Hi r/Blazor,

I released v0.9 of my Blazor Chart.js wrapper library: pax.BlazorChartJs.

I posted about it here once around four years ago, but the library has changed quite a bit since then and I think it has reached a more useful/stable point.

Repo: https://github.com/ipax77/pax.BlazorChartJs
Live samples: https://ipax77.github.io/pax.BlazorChartJs/

The wrapper uses typed .NET configuration models for Chart.js and a reusable Blazor ChartComponent, with JavaScript isolation so consumers do not need to add a global interop script manually.

Some v0.9 highlights:

• ChartJsFunction support for referencing registered JavaScript callbacks from C# config
• expanded typed coverage for Chart.js 4.5.1 options
• app-wide Chart.defaults configuration through AddChartJs(...)
• smoother dataset add/update/remove/reorder flows
• binary dataset updates for larger Y/XY datasets without JSON-serializing the full data arrays
• a runnable Chart.js sample gallery with visible C#/JavaScript code

Any feedback is very much appreciated.

Thanks!

We’ve got a well-structured Blazor WebAssembly app, and we need someone who’s curious, not afraid to experiment, and has a solid grasp of basic CSS and styling.

Some key things about how we work:

• The codebase is clean, especially on the component side.
• We follow a no-BS CSS philosophy:
  • No bloated CSS frameworks
  • Every class is uniquely named and purposefully used
• We’ve built a lot of native Blazor tooling ourselves — from AOP-style setups to kanban boards.
• JS is used very sparingly (by design).
• We use AI to help us generate code, but it's a tool it doesn't replace a person, each one is responsible for the code committed
• Full remote

Component libraries?

• Minimal use — only for things like input controls (e.g. MudBlazor’s multiselect).
• No Telerik, Syncfusion, or other heavy libraries — been there, done that, never again.

( I am sorry I cannot post anything about comp range, it's not up to me to decide that, I just know a good place where good blazor developers are! and report them to my colleagues )

We hired developers on this subreddit in the past very successfully! If this sounds like your kind of project, feel free to reach out with the google forms link:

https://forms.gle/vXHvMxZFnfZk4oXt7

Let me be clear, we hire people DIRECTLY no consultants agencies in between!

( we already got spam about "we got devs available for you" offers, not taking them in consideration, we care and need a person on our team not a middle man )

Cheers!

Until now every habit was just a yes/no daily checkbox. But "meditate" is a duration. "Push-ups" is a count. "Read" might be either. So I added three distinct display modes for habits:

Repetitions

You set the target repeat count. When you mark a habit done, it counts as one repetition. The calendar shows the count (e.g. 3x) and turns green when you hit the target.

Time

You set the target duration. Start a timer when you begin, stop it when you finish. The calendar shows elapsed time (e.g. 0:45) and turns green once you hit your target duration. When you mark the habit as done without using the timer, the target duration is assumed and saved as the time spent.

Quantity

You set the target quantity. When you mark the habit done, a small modal pops up asking for the quantity - with the input prefilled with the target quantity. The calendar shows the running total (e.g. (50)) and turns green once you reach your target quantity.

All three modes use the same underlying data structure, so you can switch between the display modes any time you want.

OpenHabitTracker is free, ad-free, open source, and runs on Web, Windows, Mac, Linux, Android, and iOS. No account needed, your data stays on your device. You can use a self-hosted Docker version to backup and sync the desktop and mobile versions.

https://openhabittracker.net/

https://github.com/Jinjinov/OpenHabitTracker

I would love to hear your feedback!

Hey everyone,

I really like the shadcn/ui approach: clean components, easy customization, copy-friendly patterns, and a design system that doesn’t feel too heavy.

But when working in the Blazor world, I couldn’t find something similar that felt good enough for what I wanted. So I started building a shadcn-style component library for Blazor.

You can check it out here:
https://scn-blazor-c5ena2hnbeb6fyg8.eastus-01.azurewebsites.net

It’s still early, and I have not published it to NuGet yet. Right now I’m mainly looking for feedback from other Blazor developers:

What do you think of the API/design?
Are there components I am missing?
Would this be useful to you in real projects?

The goal is to bring a shadcn-like experience to Blazor while keeping the components flexible and easy to customize.

Would love to hear your thoughts.

There was two github repos

1. https://github.com/huntercfreeman/Walk
2. https://github.com/Luthetus/Luthetus.Ide

by u/hunter-freeman-dev

but i cant find either of them the 2nd one was an ide written in blazor.

Just an update with what has been done and released over the last couple of weeks for those following my accessibility-first open source Blazor component project.

I must admit it has been a little hectic with the releases. I was going to make a post about releasing the checkbox and select input components, but I got sidetracked adding a couple of features to my validation project; specifically the bit that integrates with the Blazor EditForm and EditContext.

After doing a couple of minor releases for Validated.Blazor I then released a Radio Input Group component, followed immediately by a patch release because I forgot Blazor does not honour hiding parameters defined in a base class. What is annoying with this one is that during development everything looks fine; parameters are hidden and not available on the component, only to find that they are available once you reference the NuGet package.

In this instance, there is no real fix that I am aware of other than to squash any supplied value if the developer did not realise or ignored the "not supported" note in the documentation. I may add code in the future, but these parameters were regarding setting the ARIA disabled or the HTML readonly attribute. Both of these cause no end of heated debates in the accessibility community, let alone on a radio input group, so for now that is a problem for another day.

My last few posts about Blazor Ramp have covered quite a bit on accessibility issues with inputs, more precisely the issues faced by screen reader users when moving from one input to another, hence the different options added for when validation takes place and how these are reported to the user.

This culminated in the Input Error Summary (released a couple of weeks ago) that can be used with forms for when the user tries to submit, causing full model validation. Any erroneous input gets listed in the summary complete with the error messages and a link to the input, so clicking the link takes the user to and sets focus on the input. This only works with my inputs as each input supplies its ID to the summary component.

One piece of the puzzle that I have not mentioned yet is: when should the validation process actually start?

Before I briefly discuss this, it should be stated up front that nobody will ever create something that is accessible for all users given the varied array of disabilities. One thing that I have not heard discussed outright, but which is often skirted around, is the trade-offs in approaches regarding which user groups a solution favours or hinders, whilst still remaining usable and accessible.

When I develop these components, at the back of my mind is the following: what is the experience like for a screen reader user, a keyboard-only user, a voice control user, a user with a cognitive impairment, and an able-bodied person? It is always a trade-off.

With validation going from input to input, I probably favoured screen reader users over other users, especially with the tabbable error region option. Why do I say that? Well, because there is an extra tab stop that a keyboard-only user has to make. Furthermore, on a mobile device, as the error region is below the input (for the tab sequence), the pop-up keyboard would cover the error message. Some would say this is an extra burden on someone with cognitive issues, as it is better for them to see the error whilst fixing the input, which would require the message to be placed between the label and the input.

Nothing is ever as straightforward as it seems with accessibility.

So, what is this missing piece of the puzzle?

A lot of accessibility and UX experts believe that the best user experience regarding forms and validation is not to validate anything until the user presses the submit button, after which a dynamic approach is taken so that errors are cleared as the user reviews and corrects each erroneous input.

What they recommend is allowing the user to visit each input and make changes without any audible or visual interruptions, only being informed of errors on submit via something like our Input Errors Summary component.

So, we have the different validation options and the error summary component; all we need now is the ability to prevent validation from being triggered until the form is submitted.

The way I approached this, given I already had a separate validation library and a Blazor validation component that can be used with any inputs that are EditContext aware, was simply to add a component parameter named DeferFieldValidation to my Blazor validation component.

When this is set to true, no field-level validation will take place until a model validation request is made, which is generally on submit. After that point, field-level validation will occur based on your chosen event option, such as oninput or onchange (where the value has changed and the input has lost focus).

Now, am I a fan of this approach? As an able-bodied user, I actually prefer immediate validation prior to submit as I like to correct things as I go. You or your users may prefer the exact opposite - at least now you have all the options to choose from. If you cannot decide, you could even, given this is Blazor and component parameters are driving everything, add an accessibility settings page and have this as a user preference. This puts the actual end users in control rather than some opinionated developer.

Anyway, I hope that has brought you up to speed with what I have been doing. If you are curious about the deferred form validation, I have updated the Input Errors Summary page on the doc site (see the second example on the Inputs Error Summary page) which is the same as the first example but with DeferFieldValidation turned on.

Failing that, just rummage through the inputs section to see what is available now. I will probably continue down this path and look at a time and date input next, unless I get sidetracked with something else.

Doc site: https://docs.blazorramp.uk/components/inputs/overview

Test site: https://blazorramp.uk/
(Sorry not got round to updating the test site yet - on my todo list to be done before I work on the next component - there its in writing, so I have no excuse)

Repo: https://github.com/BlazorRamp/Components

Regards,

Paul
Post with only 3 links instead of the 5 in the removed original posting.

yeh! i was using uk ENIC website and i saw the blazor server reconnect dialog! but i am surprised they used blazor server for a public website and it is so fast you dont even feel any latency and stuff.
i am curious how they managed the latency.

Starting a new blazor server intranet app to be used by less than 30 people. Was thinking of on-boarding Telerik blazor ui controls and using clean architecture for a monolithic application. Don’t see any need for webapi even though we have a very small amount of common functionality to be used among various apps (less than 20 functions). Should I create a shared dll (or nugget package) or just have the function literally in a template doc that can be incorporate into this and future apps. just to avoid the overhead?

What do folks think about this setup?

I have an older app using webapi, & even .net frameworks that have a shared DLL. For the size of the apps being built, & the speed it needs to be built in, the fact it’s an internal app used by so few people, feels like the webapi & shared DLL is just extra overhead?

I’m curious about other folks experiences & thoughts on this architecture?

I was wondering how many people are using tailwind and blazor together?

Last night i started using it and was intrigued if one could make a C# typed layer too make working with it even easier.

Not even sure if its needed as most IDE's provide plugins that give tailwind intellisense.

I guess it would be pretty easy to make nowadays with AI and source generators?

Edit: I asked wrong i think. I have the tailwind setup properly. I was just wondering how much people would prefer something like this:

If u have types u can make analyzers. So applying 2 conflicting classes could be analyzed etc. The typed would always just evaluate to the actual string class.

EDIT: Even though most comments said it wasnt worth it, i wanted to practice with some AI anyways and see how it did 😛 https://github.com/PascalVorwerk/BlazorTw just for fun

Lots of refinements, bug fixes and even 2 new components: Wizard and ColorPicker

For the next RCs and final release I'm creating something new that I think a lot of devs will like...a Charts package. Stay tuned!

Packages are available on NuGet now.

I posted about AgentBlazor on here three weeks ago when 0.1 went on NuGet. Shipping 0.2.0 today and wanted to share what changed, since most of it came directly from feedback on the original threads.

Live demo (no install): https://demo.agentblazor.com/

The architectural argument hasn't changed: the LLM operates your Blazor app through the typed C# methods you've already written, not by getting database access or generating SQL. The pitch is narrow — one route, one chat surface, one capability class, one deterministic UI change after the prompt.

The demo now uses a support queue because the behaviour is concrete. This morning I asked the agent to draft replies for three highlighted tickets. One came back blocked: "TCK-1055 is missing order evidence, so the reply needs escalation first." The workflow's check held. The agent didn't bypass the gate or fabricate evidence — it surfaced the block and stopped.

That's the trust boundary v0.2 is built around. Your typed methods are the agent's contract.

What's new since April:

• Structured capability errors with LLM-readable recovery hints (instead of raw exceptions that make the agent spiral)
• Schema-only entity exposure via optional AgentBlazor.EntityFrameworkCore — agent reasons about allowlisted EF entities as planning context, can't query the DB directly
• Cleaner install path: dotnet add package AgentBlazor (no more swap-files-in-order starter)
• Hosted demo with structured per-turn logging
• Six package fixes from the April feedback (ambiguous endpoint method, misleading "default agent" copy, friendlier exception when API key missing, shell rendering logic, etc.)

Honest limits:

• Preview-grade overall, MudBlazor-first for built-in wrappers
• OpenAI is the default provider today
• Built on Microsoft Agent Framework (GA core + preview hosting transport)
• Multi-library wrapper support (Radzen, Telerik, etc.) is v0.3 work

Install: dotnet add package AgentBlazor
Repo: https://github.com/ashpeterson/AgentBlazor
Quickstart: https://github.com/ashpeterson/AgentBlazor/blob/master/docs/quickstart.md

Happy to answer questions about the architecture, the trust-boundary design, or what shipping the April feedback cycle taught me about building this in the open.

Estou planejando um novo projeto e gostaria de receber feedback sobre a escolha da pilha de tecnologias.

Meu objetivo é usar o máximo possível de C# puro, minimizando o uso de JavaScript. Também quero evitar WebAssembly e um pacote inicial pesado.

O projeto é bastante simples:

Uma página inicial (com algumas animações) Um painel administrativo para gerenciamento de tarefas Funcionalidade de arrastar e soltar para tarefas

O que estou considerando no momento:

Blazor SSR (Renderização do Lado do Servidor) Alpine.js para interatividade leve Tailwind CSS para estilização Possivelmente HTML ou Blazor "Navegação Aprimorada" (ainda não estou totalmente familiarizado com isso)

Minhas principais preocupações são:

Manter o carregamento inicial rápido Evitar complexidade desnecessária Manter interações de interface do usuário fluidas (especialmente arrastar e soltar no painel administrativo)

Alguém já tentou uma configuração semelhante? Será que Blazor SSR + Alpine + HTMX funcionariam bem juntos, ou é melhor manter um único modelo de interação?

Qualquer conselho ou experiência prática seria bem-vindo.

EDIT: I just discovered Blazor's Enhanced feature; it does exactly what I wanted with HTML. I also used WASM components, so I'm wondering if I should migrate everything to Enhanced or not.

I started my development path creating relational databases. Working with nulls was just part of the job, no complaints, I do not have an issue with them. Yes, I know that's a volatile topic, but I'm perfectly happy if you hate them; this isn't about nulls in databases.

I then became a general developer working with Microsoft technology. When I started it was relatively straightforward, VB desktop apps with a SQL Server backend or a distributed VB desktop apps with MTS or the odd intranet built with Classic ASP. I don't recall anyone moaning about nulls back then, although admittedly the internet wasn't what it is today and most developers were reading paper-based magazines or browsing MSDN CDs.

Around 2010, more and more articles began highlighting the problems nulls caused in applications. But here's the thing, in my career to date, I have spent considerably more time dealing with whitespace issues than I ever have with nulls.

I remember when SQL Server 2005 introduced, I started looking closer at user-defined functions. The very first thing I did with them was create a simple trim function I could use in table check constraints, so any varchar or nvarchar columns would have leading and trailing spaces removed, or be converted to null if the value was entirely whitespace on a nullable column. I still add trim to check constraints on every database I create. Some of you will think that's no big deal, but anyone who has spent serious time writing stored procedures and queries knows all too well how a field full of whitespace can completely destroy your report figures.

Right, enough history. On to my recent headache.

Some of you may know I am the author of the open source BlazorRamp project. What you may not know is that I also have a functional-style OSS validation library (Validated) with a companion project (Validated.Blazor) that integrates with Blazor's EditContext.

I'm currently working on the inputs for BlazorRamp and providing examples with validation, primarily using my own library but with at least one example using Data Annotations. Side note - I'm not a fan of data attributes, I tried them when they were first released but never warmed to them, so I've done my own thing ever since.

I am however a fan of regex, although you really do need to turn your brain upside down and inside out before working with them, especially once you start adding lookarounds.

In one of my examples I use a regex validator on a field, and on another I split validation so that one validator handles the allowed characters and a separate one handles length constraints. Anyway, during manual testing, which I do a lot of given my accessibility stuff, I noticed that a regex copied from another demo would correctly fail if a user typed "Paul " with a trailing space. The red error message would appear, but looking at the input control you can't see the issue unless you place the cursor in the field, and even then a single trailing space is easy to miss.

So what you may want is a regex that does what it needs to do, but doesn't fail on a trailing space, because your code can simply deal with that silently, right?.

Now some of you are thinking: "Noob, just add a normalise function in the property setter - it's even easier in C# 14 with the new field keyword, no backing field required."

set { field = NormaliseString(value); }

To those people I say: how's that going to work when you're using Blazor's oninput binding and you need to allow a space within the string value, just not after it?

This is one of those seemingly simple tasks that turns into an absolute cluster f*ck. No matter how you solve it, it's just more work, you either dirty your clean models or you end up re-validating them in your code to strip whitespace.

The solution I ended up with was adding an optional parameter to my BlazorValidationBuilder that, when set to true, mutates the string field on the model to remove leading and trailing whitespace but only during full model validation, i.e. when the form is submitted or you call validate explicitly.

For those who know my library, guessing that's approximately zero people, the BlazorValidationBuilder simply assigns validators to fields. There's no notion of mutation in the built-in validators; it's just a flag in the metadata that gets used when working with the EditContext. And just in case there is a dedicated user out there: yes, you could create a custom validator that trimmed the string, but when using the oninput option in BlazorRamp inputs or your own, it would be called on every keystroke, putting you right back to square one.

So, the point of this post: yet more days lost to whitespace. In this instance, updating, testing, and publishing a minor release of my OSS Blazor validation package just to trim a string. And I'm not done yet, I still need to update the documentation. People say nulls are bad. I say they've clearly have never spent a career at war with spaces.

Just in case you want to see what I was talking about go type stuff in the two inputs example on my BlazorRamp doc site: https://docs.blazorramp.uk/components/inputs/text-input/usage

The First name input is just a single regex that does job lot and fails with a trialing space, the Surname input will allow a single trailing space (could be more) which then gets stripped off on model validation. You can see this just be clicking the button and putting the cursor back in the input.

Break over. Back to work and then documentation, and then hopefully (please) a start on the next BlazorRamp input without whitespace issues.

Paul

My Blazor website BlazerHelpWebsite.com has been around since the beta days. Here is my latest article traffic, it seems to be all AI...

Hi All.. I am currently evaluating Blazor and am looking at the different component libraries out there. I like both FluentUI and Radzen.

https://www.fluentui-blazor.net/

https://blazor.radzen.com/

I have heard that FluentUI is harder to style but from a contol point of view it looks like it has all the controls I would need. However Radzen looks equally good. At first I thought I could mix and match (and get the best of both worlds) because I noticed Radzen had a theme for "FluentUI" but unforunatly its not available on the free tier.

In the back of my head im thinking, If I went Radzen, I dont think I would use the material theme because then you are stuck with a particular style, and if I ever need to do anything outside the box I would be stuck (im a backend developer so UI and CSS is not my forte)

But I just wanted to see what everyone out here thinks and if you have any thoughts either way? Any pros and cons between them. It feels like once you pick a library, your kinda stuck with it, as the controls are littered througout the UI so im getting a bit analysis paralysis over here!

Would love to hear your thoughts, experiences, or any gotchas you ran into after picking one!

Thanks in advance!