Cyclical dependency when upgrading to 1.6
Another question as I try to figure out why I can't update to 1.6: is
updateHookState from within useReducer in preact/hooks new? It's telling me that is where the cyclical dependency is coming from but I am unsure of how to debug this, especially since all the code before the update was minified.28 Replies
(threading to avoid cluttering main channel - I reckon it might take a bit of work to get things operational.)
So it looks like most of the actual UI logic in my game has transitioned over ok, and what's breaking is my JS-side state management. I've been using https://hookstate.js.org/ to handle global state for the UI, and it's pretty deeply embedded into this game to the point that I'm reluctant to swap it with something else (and either way, I'd want some JS-side state management anyway).
Using Hookstate with 1.5 and modifying preact/compat so that it was the same version shipped with preact worked well; this is not working for me in 1.6 with the cyclical dependency issue.
The error is showing up in the
updateHookState function from within preact itself (the version in OneJS, at least), but I've no further leads right now. I can confirm that Hookstate is the problem since removing it and displaying UI elements directly works fine.Hookstate: supercharged React.useState hook | Hookstate
The most straightforward, extensible and incredibly fast state management that is based on React state hook
@Singtaa apologies for ping [it's to add you to the thread], but do you have any insights or suggestions for debugging further with this? Have you worked with cyclical dependency errors before, or have any tips for dealing with them?
No worries. Usually the cyclic error stems from JS/Jint trying to serialize a C# object. These can happen from things like
== comparison or JSON.stringify().
Generally I'd first start with a git bisect https://git-scm.com/docs/git-bisect
to isolate the commit that broke things for youHow would we bisect in this case? There's the OneJS repository and the ScriptLib repository -- are there versions that are supposed to work with each other? Since it looks like the JS code is the one that's running foul.
Make sure everytime you test a new commit, you are deleting the ScriptLib folder as well
Yes most likely it's because of JS-side stuff, but it could also be Jint.
You don't need to worry about the ScriptLib repo for the git bisect since it's always included in the main OneJS repo as a gzip file
(Once you get the offending commit from the onejs repo, we can deduce the corresponding commit from ScriptLib.)
Also see if you can repro the cyclic error in a minimal test code that I can take a look on my side
This is the commit where the cyclical dependency issue first started showing up: https://github.com/CreepGin/OneJS/commit/ed9a7ff6f2225d479ddb00eb7029f0e61894c736
I'm going to spend some time this afternoon making a minimal repro.
I've a private repository for the minimal repo (private to avoid exposing OneJS) - which Github account should I give access to for it?
CreepGin
Got it
can you set the OneJS submodule to beyond the preact update?
(I'm also terrible with submodules)
Should be doable by going into the submodule folder (Assets/OneJS) and running
git checkout <commit number> in there, I think? If you need a new commit on my end, give me a bit.Ah okay, I think I got it
Btw, did you test the latest OneJS repo?
yes.
err, by 'latest' I'm assuming you mean the 'main' branch
yes
Hmm I'm not seeing the cyclic error yet
Did you run
node build when changing the OneJS version?the counter seems to be increasing fine
oh let me try that
I modified the tsconfig and so it doesn't auto build on file change unless
node build -w is running
(there's some gotchas in the README in the OneJS folder)Okay, a direct fix is to modify index.js line 1152 to
What's the original 'unfixed' form of the line?
!x._nextValue
basically the !x._nextValue is triggering the cyclic error and x._nextValue !== null is the workaround
Is this something you can modify? Or is it being auto generated by something else?Ah, okay. Looks like that line originally came from
ScriptLib/3rdparty/preact/hooks/index.ts on line 238.ah good, then I can just change that upstream
I'm very curious why that would cause a cyclic error, if you're willing to elaborate a bit on how you found this.
The original preact source code is littered with just
== comparisons which works fine in a pure JS environment. But when it's coupled with Jint (C#-JS interop), Jint will somehow try to serialize/stringify the C# obj (it's by design).
When I first encountered this (in trying to get Preact to work with Jint), I almost gave up because of it. It's pretty hard to debug when you don't know about the == vs === subtleties in JintAs in,
== vs a stricter === comparison?yes
Okay, that makes sense. Thank you!
You got it!
oh wait I think I got the negate sign wrong there. should be
x._nextValue === null
for completeness I'll change it to typeof x._nextValue == "undefined" || x._nextValue === null in the ScriptLib repotwo equal signs for that first one?
oh, I guess a type might not strict equal a string?
yea string cmp should be fine