TypeError: b is not a function #232
Comments
|
👋 Thanks for opening @Kingdutch! Are you using If it's still not working and you've confirmed the above, then my next guess, based on the stack trace, is that it has to do with this line inn Lastly, can you provide the output of running |
Yes! ^^ Made sure to follow the docs before posting here. This is in my yarn.lock file, indicating it resolved to 5.0.0-rc.1: Looks like there's only one actual version of I was able to clean up the stack trace by changing the source map generation in Webpack (didn't think of that last night). This confirmed your suspicion on the problem being caused by (those lines actually match the files) To debug this further I added Below contains the events as I see them in the console, along with the stacktraces from my own 1.On the first component render the hook is called and we suspend. 2.The data is successfully fetched and the component is rerendered. This calls the hook and leads to call With the following trace.3.Without going through my component the The stacktrace from my component is as follows4.React now re-renders my component (I suspect this is the Development mode behaviour). Bringing us into the The stacktrace for this scenario is as follows5.The component is now actually rerendered again and reaches `_ref3` with an undefined value without logging an additional error.6.Then the component is rendered one final time reaching `_ref3` with `undefined` but again causing the `Uncaught TypeError: ref is undefined` error.7.Now finally the `react_devtools_backend.js` takes over and shows me an error message, stopping the execution of the React application.8.There is another |
|
I've rebuilt React in Initial render and suspend (data fetching happens here....) With resolved data (still renders twice?): The following two errors come right after the previous rendering logs. The first in The second from |
|
Found a solution!! :D So adding the I'll create a PR with a change to the repository. I think it's safe to manually add that in a minor version of |
|
Hiya, just following this up from: urql-graphql/urql#1214 This isn't quite as simple yet, and I'd love to find a solution for this that will keep this running but we've actually explicitly deferred the upgrade of There are some questions I'll need to look into before we can make any changes. The main problem is that once we'd upgrade Wonka we'd have to make sure that it's impossible to have two versions of Wonka streams in one system, e.g. by having outdated exchanges. Typically the Also, there were issues with BuckleScript@<=8 before that meant that |
Right, yes, this was recommended by the documentation for
Sorry about that ^^ Do you still want me to open an issue in the
I see, yeah my PR noted that ideally it doesn't handle the internals at all but defers to Wonka. Since this is only used in 1 case, would an
Right, although
Right, this is what I mentioned at the start of this issue, where The main cause of the issue here seems to be that Wonka (>=5), as distributed on npm, has been compiled with BuckleScript/ReScript >= 8.0 since This also means that the incompatibility is not dependent on whatever version of BuckleScript/ReScript my project is using, but this is an incompatibility between The change I proposed in the PR would add the variant encoding for the single usage in Reduced reproductionI've created a repository with a simple test-case that doesn't contain In the version without resolution entry the error doesn't occur because In the version with resolution entry there is only one version of Wonka installed (as visible in the diff). This causes suspense with You can see the error for yourself by cloning the repository to the desired commit and running What my PR tried to changeThe PR I proposed (I've adjusted it to include a changeset and made sure all the checks passed locally, sorry for not reading the contributors guide beforehand), added the fields for variant resolution as used in ReScript >= 8 (and as a result Wonka 5) while leaving the fields for variant resolution in ReScript < 8 intact. This allows An alternativeAs you mention that the update for Wonka to ReScript has been purposefully held up, then it appears that the compilation of The blogpost that described the variant representation change can be found in the ReScript blog archives: https://rescript-lang.org/blog/overview-of-new_encoding#variant-internal |
|
Yep, I'm aware of all of the changes and the compilation differences (which is why v5 exists in the first place) What I'm more concerned about us that we have to switch all of urql over to the new compilation sooner or later. What that means is that people may upgrade some package and get incompatible exchanges created using different versions of Wonka. I have come up with a migration plan though which may work:
I have a branch which does all of this (minus of course changes to the version of Wonka) but this will need some careful planning on our part 😅🤔 https://github.com/FormidableLabs/urql/tree/fix/pure-tosuspensesource |
|
Just for my own understanding I wanted to figure out how everything tied together. The upgrade to BuckleScript 8 for Wonka happens in 0no-co/wonka#88 and notes
BuckleScript's variant implementation is directly exposed to TypeScript through https://github.com/kitten/wonka/blob/master/src/shims/Js.shim.ts (and a flow file is also generated) which means that any implementation has to work with the fields in the records directly to figure out the state of a signal. The only instance of this that I can find in the The result of this exposure is the bug that started this issue. It also means that if BuckleScript decides at any point to change its variant representation again (for performance/space saving/whatever reasons), this will require a major version of Wonka that ripples through its ecosystem. My knowledge of TypeScript is too limited to find a solution, but I'm wondering if there's a way to encode BuckleScript's variant representation in TypeScript so we can prevent such breaking changes in the future (and only need it once). |
Ha! Yeah as you can see above, I was tracing out the history here to figure this out myself. If anyone else comes to this and they want to know the course of events, now they know too :D The multiple copies issue is something that yarn's
The only real offence I see is that it tries to manually alter an objects' variant type instead of letting Wonka do this. If What's the best way to see the other breaking changes in Wonka moving from 4 -> 5? I guess without having written my own exchange this is about the limit of my understanding ^^' EDIT: Took a look at the branch you linked. I like the approach! That at least should make it clearer to users what's going on and prevent subtle bugs due to incompatibility once a new release of urql is made! :D It'd be interesting to see if we can create a codemod to help upgrade any exchanges that may be using the internals directly. Alternatively, if it's determined this is bad practice altogether and shouldn't be done. Perhaps a development mode check or linting rule can identify that it's happening and warn that it makes upgrading more difficult. |
|
Not quite; so basically if you have two packages
Precisely, that's the other issue. I'm also not convinced that's the solution, because we're not aiming to support a situation where one package manager is more preferable to another in all cases.
Like I said, yea, we had several versions of this which all didn't use internals, but testing new versions of
None do; even custom ones I wouldn't expect to since it's never necessary. So I don't really mind breakage if some do, because at that point breakage is expected. The main issue here is just addressing an upgrade across our numerous exchange packages. So it's not a technical or code problem per se, it's a problem of convenience for users and of the process of doing so safely, since if this causes confusing issues, it's intransparent; image everyone who uses |
|
Right, so if I understand correctly. Once urql's current use of Wonka's internals is removed then that should mean that no (well behaving/supported) exchanges should be using Wonka's internals. That means that (for this particular issue) upgrading to Wonka 5 is a non-breaking change from urql`s point of view. (I don't know if there are other breaking changes in Wonka?) The only problem that's left is if exchanges' requirements cause a mixed set of wonka versions to be installed by a package manager. Passing data between those two instances would cause users a bad time. Your branch includes a check that detects this painful scenario. However, it assumes that wonka 4.1 is the only correct version. If the only breaking change between wonka 4 and 5 is the change in internal representation. Then any well behaved exchange that doesn't touch the internal representation itself can already mark itself compatible with wonka 5 (i.e. update dependencies to That means your check could be relaxed to only validate that all exchanges use the same version of Wonka, without enforcing a specific one. This means all exchanges can mark their compatibility with the future version but users only actually have to switch once all are compatible. (If there are other breaking changes between wonka 4 -> 5 then the above goes out the window) |
|
@Kingdutch I've attached the future label to this since it'll be coming along with a future release of |
|
You're most welcome. Thanks to Phil and yourself for the very rapid responses and for providing insights into the issues and roadmap! If there is anything I can help with to push this forward in |
Using React suspense (
0.0.0-experimental-d7382b6c4) with reason-urql I run into the following error.A console.log before the useQuery hook invocation seems to indicate this happens after the rerender caused by React development mode (the network request completes but contains the following error.
This is produced by the query
Phil (Kitten) suggested that it could be caused by multiple instances of Wonka. I'm not sure how I'd debug that. However, I could come up with a possibility for that which I would not know how to resolve:
urqlwhich is ignored by ReScript and that import will load./dist/wonka.mjsusing import.The text was updated successfully, but these errors were encountered: