Next.js App Router, React v.19 deprecates forwardRef, other fixes #3
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi, since I use this template and have been experimenting with it, I wanted to give back a little and submit this PR. I've summarized my changes below. Hope this is helpful and please leave as much feedback as you want, as I'm curious what you think. I also realize there is a chance you may want to split some aspects of this up from others, but hopefully in totality it makes sense and the diff is manageable. Thank you! :)
List/explanation of changes:
1. Update React deps to React v.19 (latest stable/production ready) and Next.js v.15 (latest stable/production ready).
2. React v.19 removes
forwardRef
so now we can just pass inref
prop toPhaserGame.tsx
. This simplifiesPhaserGame.tsx
component signature significantly, and makes it easier to understand in the template.const game = useRef<Phaser.Game | null>(null!);
). I maybe missing something regarding why this is necessary, but I removed this to further simplify PhaserGame.tsx, so now it just assigns a new scene (without a ref, as before) in thescene
key,game
basically stays the same as it is only written to at init. There was nothing wrong with the extra ref, it just seemed unnecessary and confusing in context of the template, when someone potentially new to Phaser<>React will want to understand how they work together. For that reason I opted for just the one ref. Apologies if this is wrong for some reason, in which case I'll be curious to learn about that!3. Clean up some re-rendering and naming issues.
[ref]
is actually not needed in any ofPhaserGame.tsx
dep arrays, I just added them back because I believe some linters may complain. But I believe beyond that, they are not necessary. However the extra dep here was not needed, and was causing the useEffect block to run more often than necessary, although it didn't cause a huge problem re some quick perf tests, re-running the entire useEffect block because of that dep is best avoided, since I believe the intention is just to setup the EventEmitters and their listeners. This also simplifies the template code, and passes down a simpler setState function (setCanMoveSprite
), which is more idiomatic React. This also removes this line:<PhaserGame ref={phaserRef} currentActiveScene={currentScene} />
which I personally found very confusing when first interacting with this template, as really this is just a way to set some state based off the EventEmitter, but reads like we are passing down the currentScene or its instance. Hopefully you agree the way I have done it here is more clear.Other notes: When experimenting with this template, I did wrap the entire PhaserGame.tsx in
memo()
, and the code worked, but it did not influence performance by much if at all in my quick tests. The PhaserGame.tsx actually re-renders fairly frequently given the parent component hooks into a fair amount of game state/events (likesetSpritePosition
) but it seems the React reconciler handles this fine, furthermore given most ofPhaserGame
is just a container for the phaser game instance/canvas, wrapping inmemo()
seemed premature and also potentially confusing, but it was interesting. Also fun to note given how the new Next.js APIs, more of this template (really the non-phaser UI parts) are now statically generated (note the newdynamic
API). Meaning, if the game takes really long to load for some reason or you disable javascript, at least you can see the DOM buttons! :DThanks for reading, lmk if I anything else I can do to help merge :)