React to .NET Was Always a Joke
Back in 2020, I built a free online tool that would convert your React component into a .NET component. No install required.
Now with AI, I don’t think we really need it. You’ll find it here for posterity.
751 entries on php, laravel, business, management - and even iot. Looking for something a bit meatier? You might be the sort of person who likes my books.
Back in 2020, I built a free online tool that would convert your React component into a .NET component. No install required.
Now with AI, I don’t think we really need it. You’ll find it here for posterity.
When I first started using Laravel, I really didn’t like the global middleware that trimmed strings. But after a while, it became an irreplaceable part of my tool belt, and I am a convert.
I became so used to this that the first time a user used my Filament input and I saw a space after some text, I was really confused. Why did this happen?
Let me tell you how to fix this on the form itself, how to do it globally, and what that might cause a problem with.
Laravel is always giving us little helpers.
One of which is Blade’s @foreach that gives you a $loop variable.
Inside the loop you get things like $loop->index and $loop->iteration, plus the two I want to talk about today: $loop->first and $loop->last.
first and last are boolean values that tell you if this is the first iteration or the last iteration of the loop.
Pretty self-explanatory.
But far too many times I see people abusing these for style - when they should be for flow control.
I’ve been a huge fan of automated software testing for years. I tend to reach for unit tests over end-to-end (e2e) tests. This is probably because of two reasons: a focus on back-end work (primarily) and e2e testing was slow compared to my targeted unit tests.
With automated AI tooling now, though, I think the tide is changing. I still value my unit tests, but e2e is becoming my champion.
I’ll explain how and why my mind changed:
When I see something like this, I immediately want to “fix” it.
Let’s take a look at this job:
Maybe I’m behind. But I like to think of it as conservative. Parallel unit testing has been around for a while, and I haven’t really reached for it until recently.
This isn’t about not wanting to change, though. It’s about using the proper tools for the job, and only when necessary.
Or at least, that’s how I rationalize my delay. But maybe you’re in the same place. Let’s dig into why I waited, why you might want to wait still, and the reasons why this works now.
Sometimes I look back at my older open source work, or talks, and feel a little bit ashamed.
“That’s not right.” “That’s not how you’d do it” (or not how I’d do it now).
And the times I re-invented the wheel when packages were already there…
As embarrassing as that seems now, there was a good reason for that.
Doing things that others have done, but in our own way, is a synthesis that helps us learn.
Let’s not forget about that.
Pennant defaults to the database driver, and most tutorials follow that lead. That’s fine for long-lived flags, but it adds a row and a query for every feature resolution.
Laravel’s default behavior on a failed FormRequest validation is to throw a ValidationException, which the framework’s exception handler converts into a redirect to the previous URL with the input flashed to the session and errors attached.
That works perfectly when a person submits the form as the redirect lands them back on that page with the errors.
It breaks down when the form submits itself, for example a bookmark to a GET form with validation, or submitting something into a target="_blank" (like PDF generation).