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
Using a second comparative state is still not very intuitive today, but before batched updates, it also created extra re-renders
Before useEffectEvent, useRef + useEffect was the only way to use functions with unstable references in another useEffect
Optimistic state, asynchronous state, and so on
Before useEffectEvent, useRef + useEffect was the only way to use functions with unstable references in another useEffect
Optimistic state, asynchronous state, and so on
November 6, 2025 at 10:10 PM
Using a second comparative state is still not very intuitive today, but before batched updates, it also created extra re-renders
Before useEffectEvent, useRef + useEffect was the only way to use functions with unstable references in another useEffect
Optimistic state, asynchronous state, and so on
Before useEffectEvent, useRef + useEffect was the only way to use functions with unstable references in another useEffect
Optimistic state, asynchronous state, and so on
In the case of React, there's also the historical factor that for a long time, useEffect was the only way to achieve many things
Before useSyncExternalStore, it was the only way to sync with external state
Before useSyncExternalStore, it was the only way to sync with external state
November 6, 2025 at 10:10 PM
In the case of React, there's also the historical factor that for a long time, useEffect was the only way to achieve many things
Before useSyncExternalStore, it was the only way to sync with external state
Before useSyncExternalStore, it was the only way to sync with external state
I think useEffect gets a bad rep because of the re-rendering model
In any framework, changing state within an effect is suboptimal
In React, even when it doesn't create an infinite loop, it's still a ticking time bomb waiting to explode your app's performance by creating additional rendering cycles.
In any framework, changing state within an effect is suboptimal
In React, even when it doesn't create an infinite loop, it's still a ticking time bomb waiting to explode your app's performance by creating additional rendering cycles.
November 6, 2025 at 7:03 PM
I think useEffect gets a bad rep because of the re-rendering model
In any framework, changing state within an effect is suboptimal
In React, even when it doesn't create an infinite loop, it's still a ticking time bomb waiting to explode your app's performance by creating additional rendering cycles.
In any framework, changing state within an effect is suboptimal
In React, even when it doesn't create an infinite loop, it's still a ticking time bomb waiting to explode your app's performance by creating additional rendering cycles.
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
Svelte v3/4 used labels to indicate derivations and effects
v4.svelte.dev/docs/svelte-...
v4.svelte.dev/docs/svelte-...
Svelte components • Docs • Svelte
Svelte components • Svelte documentation
v4.svelte.dev
November 4, 2025 at 1:35 PM
Svelte v3/4 used labels to indicate derivations and effects
v4.svelte.dev/docs/svelte-...
v4.svelte.dev/docs/svelte-...
I don't know about other frameworks, but Svelte has pretty good first party support for handling forms
svelte.dev/docs/kit/rem...
svelte.dev/docs/kit/rem...
Remote functions • SvelteKit Docs
Remote functions • SvelteKit documentation
svelte.dev
October 27, 2025 at 8:58 PM
I don't know about other frameworks, but Svelte has pretty good first party support for handling forms
svelte.dev/docs/kit/rem...
svelte.dev/docs/kit/rem...
If I understand correctly, this only occurs if you use resetQueries and the reseted query doesn't have an initialData (which doesn't make sense since the purpose of resetQueries is to reset to the initial value)
But even in this case, useDeferredValue can be used to avoid displaying the fallback
But even in this case, useDeferredValue can be used to avoid displaying the fallback
React Playground
URL-based React Playground. Craft, experiment, and collaborate with ease using our sandbox. Build, test, and share your concepts hassle-free. No need for sign-in: your creations are stored directly in...
reactplayground.vercel.app
October 23, 2025 at 2:02 PM
If I understand correctly, this only occurs if you use resetQueries and the reseted query doesn't have an initialData (which doesn't make sense since the purpose of resetQueries is to reset to the initial value)
But even in this case, useDeferredValue can be used to avoid displaying the fallback
But even in this case, useDeferredValue can be used to avoid displaying the fallback
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
The thread was about react.transition vs react.useTransition
React-query had very little to do with the problem
So much so that it was necessary to use both to reproduce the issue.
bsky.app/profile/rick...
React-query had very little to do with the problem
So much so that it was necessary to use both to reproduce the issue.
bsky.app/profile/rick...
October 23, 2025 at 1:02 PM
The thread was about react.transition vs react.useTransition
React-query had very little to do with the problem
So much so that it was necessary to use both to reproduce the issue.
bsky.app/profile/rick...
React-query had very little to do with the problem
So much so that it was necessary to use both to reproduce the issue.
bsky.app/profile/rick...
You need to indicate the transition in the data that will result in the creation of the new promise, not in the promise itself.
Using useDeferredValue in the query parameters has been working for me, no fallbacks after the initial load.
Using useDeferredValue in the query parameters has been working for me, no fallbacks after the initial load.
October 23, 2025 at 12:12 PM
You need to indicate the transition in the data that will result in the creation of the new promise, not in the promise itself.
Using useDeferredValue in the query parameters has been working for me, no fallbacks after the initial load.
Using useDeferredValue in the query parameters has been working for me, no fallbacks after the initial load.
Doesn't react-query have the useSuspenseQuery hook?
Additionally, it is possible to take the promise from the query and use "use" directly
Additionally, it is possible to take the promise from the query and use "use" directly
October 23, 2025 at 11:46 AM
Doesn't react-query have the useSuspenseQuery hook?
Additionally, it is possible to take the promise from the query and use "use" directly
Additionally, it is possible to take the promise from the query and use "use" directly
I mean, you can abstract
function getLinkProps(href) {
return {
href,
class: {
active: page.url.pathname === href
}
}
}
<a {...getLinkProps('/some/path')} />
But in the end it's just a matter of preference
function getLinkProps(href) {
return {
href,
class: {
active: page.url.pathname === href
}
}
}
<a {...getLinkProps('/some/path')} />
But in the end it's just a matter of preference
October 21, 2025 at 3:23 AM
I mean, you can abstract
function getLinkProps(href) {
return {
href,
class: {
active: page.url.pathname === href
}
}
}
<a {...getLinkProps('/some/path')} />
But in the end it's just a matter of preference
function getLinkProps(href) {
return {
href,
class: {
active: page.url.pathname === href
}
}
}
<a {...getLinkProps('/some/path')} />
But in the end it's just a matter of preference
Attachments are already reactive, so you don't need the effect
Personally I prefer using the new built-in clsx in the class prop instead of toggling class imperatively, to remove the need for :global
Personally I prefer using the new built-in clsx in the class prop instead of toggling class imperatively, to remove the need for :global
October 21, 2025 at 3:02 AM
Attachments are already reactive, so you don't need the effect
Personally I prefer using the new built-in clsx in the class prop instead of toggling class imperatively, to remove the need for :global
Personally I prefer using the new built-in clsx in the class prop instead of toggling class imperatively, to remove the need for :global
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
Because it's more efficient, not because manually deriving will break your app
In any other framework this is suboptimal, in react this is a minefield:
let count = $state(0)
let double = $state(count * 2)
$effect(() => {
double = count * 2
})
svelte.dev/playground/h...
In any other framework this is suboptimal, in react this is a minefield:
let count = $state(0)
let double = $state(count * 2)
$effect(() => {
double = count * 2
})
svelte.dev/playground/h...
Hello world • Playground • Svelte
Web development for the rest of us
svelte.dev
October 12, 2025 at 4:51 PM
Because it's more efficient, not because manually deriving will break your app
In any other framework this is suboptimal, in react this is a minefield:
let count = $state(0)
let double = $state(count * 2)
$effect(() => {
double = count * 2
})
svelte.dev/playground/h...
In any other framework this is suboptimal, in react this is a minefield:
let count = $state(0)
let double = $state(count * 2)
$effect(() => {
double = count * 2
})
svelte.dev/playground/h...
If changing a state within the effect resulted in simply CHANGING THE STATE, nothing unexpected would happen
No wonder all frameworks that came after React hooks copied useEffect api and still don't have 90% of the problems that "useEffect has"
No wonder all frameworks that came after React hooks copied useEffect api and still don't have 90% of the problems that "useEffect has"
October 12, 2025 at 2:56 PM
If changing a state within the effect resulted in simply CHANGING THE STATE, nothing unexpected would happen
No wonder all frameworks that came after React hooks copied useEffect api and still don't have 90% of the problems that "useEffect has"
No wonder all frameworks that came after React hooks copied useEffect api and still don't have 90% of the problems that "useEffect has"
I disagree
UseEffect is actually a good API
The problem (specifically in React) is the re-rendering model
What caused the problem in Cloudflare's case, for example, was that changing state within the effect causes the component to be re-executed, and consequently, your component to be recreated
UseEffect is actually a good API
The problem (specifically in React) is the re-rendering model
What caused the problem in Cloudflare's case, for example, was that changing state within the effect causes the component to be re-executed, and consequently, your component to be recreated
October 12, 2025 at 2:56 PM
I disagree
UseEffect is actually a good API
The problem (specifically in React) is the re-rendering model
What caused the problem in Cloudflare's case, for example, was that changing state within the effect causes the component to be re-executed, and consequently, your component to be recreated
UseEffect is actually a good API
The problem (specifically in React) is the re-rendering model
What caused the problem in Cloudflare's case, for example, was that changing state within the effect causes the component to be re-executed, and consequently, your component to be recreated
This is the first time I've seen someone prefer control flow as attributes instead of having indentation and a real scope block view.
October 7, 2025 at 9:47 AM
This is the first time I've seen someone prefer control flow as attributes instead of having indentation and a real scope block view.
experimental_prefetchInRender works great with svelte 5
svelte.dev/playground/h...
svelte.dev/playground/h...
Hello world • Playground • Svelte
Web development for the rest of us
svelte.dev
September 30, 2025 at 7:22 PM
experimental_prefetchInRender works great with svelte 5
svelte.dev/playground/h...
svelte.dev/playground/h...
I have data that is displayed both in pagination and infinite scrolling, and it would be really nice if I could use the same query for both
Also, infinite queries are simpler to handle when it's necessary to invalidate a list
Also, infinite queries are simpler to handle when it's necessary to invalidate a list
September 27, 2025 at 7:28 PM
I have data that is displayed both in pagination and infinite scrolling, and it would be really nice if I could use the same query for both
Also, infinite queries are simpler to handle when it's necessary to invalidate a list
Also, infinite queries are simpler to handle when it's necessary to invalidate a list