Thiago
@thiagolino8.bsky.social
Full-Stack Dev 💻 | Tech enthusiast 🚀 | Curious mind 💡
Exploring innovation, digital culture, and the future of tech 🌐
Here to connect, learn, and share insights ✨
https://www.linkedin.com/in/thiago-lino-gomes-5812581bb
https://github.com/thiagolino8
Exploring innovation, digital culture, and the future of tech 🌐
Here to connect, learn, and share insights ✨
https://www.linkedin.com/in/thiago-lino-gomes-5812581bb
https://github.com/thiagolino8
In V5, they started using "runes," which are special operators used by the compiler
Operators like `import()` or `super()`, which look like functions, are, as far as TS is concerned, just functions but they have their own specific usage rules
This is what MDN calls a function-like expression
Operators like `import()` or `super()`, which look like functions, are, as far as TS is concerned, just functions but they have their own specific usage rules
This is what MDN calls a function-like expression
November 4, 2025 at 1:41 PM
In V5, they started using "runes," which are special operators used by the compiler
Operators like `import()` or `super()`, which look like functions, are, as far as TS is concerned, just functions but they have their own specific usage rules
This is what MDN calls a function-like expression
Operators like `import()` or `super()`, which look like functions, are, as far as TS is concerned, just functions but they have their own specific usage rules
This is what MDN calls a function-like expression
I have about 67 uses of useSuspenseQuery in my main app All used within custom hooks that are mostly used more than once
So in total, there are at least 100 different uses of useSuspenseQuery
It's an app with a lot of data updates and derivations
Nowhere is there any fallback after the initial load
So in total, there are at least 100 different uses of useSuspenseQuery
It's an app with a lot of data updates and derivations
Nowhere is there any fallback after the initial load
October 23, 2025 at 1:02 PM
I have about 67 uses of useSuspenseQuery in my main app All used within custom hooks that are mostly used more than once
So in total, there are at least 100 different uses of useSuspenseQuery
It's an app with a lot of data updates and derivations
Nowhere is there any fallback after the initial load
So in total, there are at least 100 different uses of useSuspenseQuery
It's an app with a lot of data updates and derivations
Nowhere is there any fallback after the initial load
It gets even simpler with async svelte
Bonus: no flickering on mount
Bonus: no flickering on mount
October 20, 2025 at 1:24 AM
It gets even simpler with async svelte
Bonus: no flickering on mount
Bonus: no flickering on mount
In this case, it's simpler to just move everything to the event.
But I'm working on an app where I need to change a state after a formAction, and it would be really helpful if I could do this:
But I'm working on an app where I need to change a state after a formAction, and it would be really helpful if I could do this:
September 27, 2025 at 7:10 PM
In this case, it's simpler to just move everything to the event.
But I'm working on an app where I need to change a state after a formAction, and it would be really helpful if I could do this:
But I'm working on an app where I need to change a state after a formAction, and it would be really helpful if I could do this:
When creating my examples, I tried to do something similar, placing the promises in states instead of using react query
But instead of doing this in an event, I tried to do it during rendering, using the example on the blog "You Might Not Need an Effect" as a basis
But instead of doing this in an event, I tried to do it during rendering, using the example on the blog "You Might Not Need an Effect" as a basis
September 27, 2025 at 7:10 PM
When creating my examples, I tried to do something similar, placing the promises in states instead of using react query
But instead of doing this in an event, I tried to do it during rendering, using the example on the blog "You Might Not Need an Effect" as a basis
But instead of doing this in an event, I tried to do it during rendering, using the example on the blog "You Might Not Need an Effect" as a basis
It's on purpose, you can ignore these "stillborn" updates by using an abortSignal coming from: svelte.dev/docs/svelte/...
September 25, 2025 at 9:20 PM
It's on purpose, you can ignore these "stillborn" updates by using an abortSignal coming from: svelte.dev/docs/svelte/...
In react the experience is basically the same but with inconsistent states (tearing on count) and after the transitions finish everything freezes for a moment
September 25, 2025 at 4:47 PM
In react the experience is basically the same but with inconsistent states (tearing on count) and after the transitions finish everything freezes for a moment
My experience with million is: updates happen immediately, no missed click events, the scan loses very little performance, the states are consistent everywhere
September 25, 2025 at 4:47 PM
My experience with million is: updates happen immediately, no missed click events, the scan loses very little performance, the states are consistent everywhere
Final version, you can choose between inline svg and img
April 28, 2025 at 12:38 PM
Final version, you can choose between inline svg and img
Oops, the css was wrong
April 28, 2025 at 11:10 AM
Oops, the css was wrong
And if you remove the eager parameter you can use dynamic imports to avoid importing all the svgs when you only want one
April 28, 2025 at 11:07 AM
And if you remove the eager parameter you can use dynamic imports to avoid importing all the svgs when you only want one
What I usually do is use import.meta.glob + '?raw' query + {@html}
This way each svg is in its own file and there is no need to add a new export every time
I believe hydration is also simpler using {@html} (not sure)
This way each svg is in its own file and there is no need to add a new export every time
I believe hydration is also simpler using {@html} (not sure)
April 28, 2025 at 10:55 AM
What I usually do is use import.meta.glob + '?raw' query + {@html}
This way each svg is in its own file and there is no need to add a new export every time
I believe hydration is also simpler using {@html} (not sure)
This way each svg is in its own file and there is no need to add a new export every time
I believe hydration is also simpler using {@html} (not sure)
Time to cleanup your tabs
March 4, 2025 at 6:35 PM
Time to cleanup your tabs
It's really strange that a library that doesn't have an official framework is so afraid to recommend the main way of creating apps nowadays
Meanwhile, even libraries that have an official framework are still strongly recommending Vite
Meanwhile, even libraries that have an official framework are still strongly recommending Vite
January 26, 2025 at 6:13 PM
It's really strange that a library that doesn't have an official framework is so afraid to recommend the main way of creating apps nowadays
Meanwhile, even libraries that have an official framework are still strongly recommending Vite
Meanwhile, even libraries that have an official framework are still strongly recommending Vite
Me everytime I restart typescript server and the errors don't go away
January 7, 2025 at 7:37 PM
Me everytime I restart typescript server and the errors don't go away
In the end I ended up creating my own solution that better meets my preferences and needs, with bindings for react, svelte, vue, solid and preact
I'll publish it early next year probably, after polishing it for general use.
I'll publish it early next year probably, after polishing it for general use.
December 27, 2024 at 2:06 PM
In the end I ended up creating my own solution that better meets my preferences and needs, with bindings for react, svelte, vue, solid and preact
I'll publish it early next year probably, after polishing it for general use.
I'll publish it early next year probably, after polishing it for general use.
The most recent optimization that comes to mind is for classic vs for of vs forEach
There was a chasm of difference between them progressively
Nowadays, not only are they very close, but forEach is faster for most cases
jsbm.dev/lujhRyWERs8P5
There was a chasm of difference between them progressively
Nowadays, not only are they very close, but forEach is faster for most cases
jsbm.dev/lujhRyWERs8P5
December 9, 2024 at 12:53 PM
The most recent optimization that comes to mind is for classic vs for of vs forEach
There was a chasm of difference between them progressively
Nowadays, not only are they very close, but forEach is faster for most cases
jsbm.dev/lujhRyWERs8P5
There was a chasm of difference between them progressively
Nowadays, not only are they very close, but forEach is faster for most cases
jsbm.dev/lujhRyWERs8P5
The difference seems to be using arrays with empty values
Spread turns empty values into undefined, .concat() keeps empty values
Using arrays with values, .concat() is more than 6x faster
jsbm.dev/jt5bK4S7gUaqC
Spread turns empty values into undefined, .concat() keeps empty values
Using arrays with values, .concat() is more than 6x faster
jsbm.dev/jt5bK4S7gUaqC
December 8, 2024 at 9:54 PM
The difference seems to be using arrays with empty values
Spread turns empty values into undefined, .concat() keeps empty values
Using arrays with values, .concat() is more than 6x faster
jsbm.dev/jt5bK4S7gUaqC
Spread turns empty values into undefined, .concat() keeps empty values
Using arrays with values, .concat() is more than 6x faster
jsbm.dev/jt5bK4S7gUaqC
