danieleirsuti.dev
I write javascript stuff to pay my rent
Member of GDG Pescara
82 posts
28 followers
168 following
Regular Contributor
Active Commenter
comment in response to
post
Soft assertions. main.vitest.dev/api/expect.h...
comment in response to
post
This doesn't feel right to me because it's overriding the entire Location class and "window.open" at a global level. š¤
Is this a bad practice? Any insights from test experts?
comment in response to
post
feel you. I tried to upgrade to version 4 in my Astro blog a few days ago, and it worked beautifully in dev but not in prod and all CSS modules disappears for some reason
comment in response to
post
Maybe because most influent JS people are tech bros who likes Musk and his enlightened vision of the world.
I don't miss that place, less contents but more quality than noise
comment in response to
post
Nowadays itās hard to imagine an endpoint without openapi spec but sadly it happensā¦ very often.
Anyway, this is readable, I like it!
comment in response to
post
These people donāt look beyond their own garden.
Sometimes I think about how we (as collectivity) ended up like this
comment in response to
post
oof github.com/vitejs/vite/...
comment in response to
post
I'm sure is related to css modules but I'm lost š¤·āāļø
comment in response to
post
it's time to shine.
now in cubital characters: D E P R E C A T E D š
comment in response to
post
We canāt be friends with nazis I guess š¤·āāļø
Sorry, I couldnāt resist
comment in response to
post
ah this works
comment in response to
post
github.com/vitest-dev/v...
comment in response to
post
too late to correct, I left a "e.message" that should be "query.error.message" š
comment in response to
post
Good point I remember that! but the way I propose is something different, more like a "select" but for the errors
comment in response to
post
*queryErrorFn
comment in response to
post
I was wondering: what if instead declaring type (which is unsafe) you donāt add another property fn for error only? In that way you can infer error from that function in a more ergonomic way.
Like errorFn or errorQueryFn
comment in response to
post
The unique way of handle error properly (I use) is using an extended class of error and check the instance (with some property to check, eventually)
comment in response to
post
Mmmh donāt like it, doesnāt ensure any kind of safety
comment in response to
post
I love how cool your site is š
comment in response to
post
It also means dealing with toxicity, stress and over exposure, in the worst case a burnout.
Not sure is worth it but ehi, šø
comment in response to
post
It's not actually, but it's close, I was talking about this one:
sergiodxa.com/tutorials/us...
Although after going through it, it's pretty ancient š
but the code would look more or less the same nowadays.
comment in response to
post
I always hoped that people like you would eventually leave X. Following people there meant constantly being distracted by memes, bots, and rage bait. It was hard for me to say, āEnough, Iām out,ā because what truly matters is the people, not the platform. Iām glad finally a lot of people moved here
comment in response to
post
Or use a framework, at this point
comment in response to
post
Cool, very curious how to implement revalidation after mutation. Is it documented? I have not found anything about that (but maybe Iām blind š
)
comment in response to
post
ābackend for frontendā pattern. itās when your backend isnāt trying to be some agnostic super general API but when itās targeted to specific screens. medium.com/mobilepeople...
comment in response to
post
I also oppose the marketing around RSCs. I think they deserve even more education than we have previously put into any other framework feature.
All of these things can be fixed or better understood with time and effort though.
I am trying my hardest to help these points get better.
comment in response to
post
CSR. We depend upon a php monolith