Would it be possible to conditionally run useRealtimeRun? For example, by adding a skip variable, similar to Apollo Client, so that it doesn't run when skip is true?
#Conditionally run `useRealtimeRun`
open cipher
naive sparrow
@coral swan this is a good idea. Otherwise you get the annoying different number of hooks error
coral swan
👍
open cipher
@coral swan @naive sparrow
I was wondering if this is currently in progress?
coral swan
Yup it will go live with this PR: https://github.com/triggerdotdev/trigger.dev/pull/1470
open cipher
Yup it will go live with this PR: https://github.com/triggerdotdev/trigger.dev/p...
Thanks for the update and quick response 👍
open cipher
Hello,
I noticed that you merged and deployed it—thanks for that!
I tried using it, but I’m getting the following error:
@trigger__dev_react-hooks.js?v=eb1517e7:13205 Uncaught TypeError: (0 , import_react4.useId) is not a function
I’m currently using React 17, but I see that useId was introduced in React 18.
How can I fix this?
naive sparrow
@coral swan if we’re using that we can probably use a polyfill
open cipher
<@166949736065138688> if we’re using that we can probably use a polyfill
Thank you. May I ask if this will be included in the next release? 🙏
naive sparrow
Sorry, we're still considering whether we will do this.
Is there something holding you back from React 18? The upgrade to 19 is painful but I think the upgrade from 17 to 18 was seamless for almost everyone. If we support 17 now we will have to support it for a long time and it's already over 4 years old.
open cipher
Sorry, we're still considering whether we will do this.
Is there something hol...
@naive sparrow
Unfortunately, one reason is that we are still using React Router v5, while React 18 requires React Router v6. Upgrading to v6 involves significant breaking changes, and our current focus on higher-priority tasks has delayed this upgrade.
open cipher
Hey @naive sparrow / @coral swan
I just wanted to check if you've decided to support React 17?
naive sparrow
It's tricky because the React 18+ useId hook does some special things that make it work with server side rendering by keeping the ID stable across the server-client boundary. We really need to use that hook for React 18+.
So I think the only practical solution would be for us to have our own hook that used useId when available and fallback to a dumber id if it's not.
It's generally quite tricky to get feature detection like that working reliably across different runtimes and in the browser. It will need careful testing across different React versions to check it works