Added documentation for NextJS and SolidJS

[Dryspell]

Created new documentation pages for NextJS and SolidJS and I updated the package JSON for docusaurus to be on the latest version. I also ran npm update and npm audit fix which reflects the changes in the package lock.

[eonarheim]

@Dryspell Awesome! We actually need to keep docusaurus pinned at 3.0.0 because we have a specific patch for 3.0.0 at the moment.

[eonarheim]

Switch docusaurus deps back to pinned 3.0.0, normally updating this would be okay but we have a 3.0.0 specific patch at the moment

[eonarheim]

@Dryspell I'm going to have some more JSX familiar peeps look at this too (since I'm not very familiar myself)

[mattjennings]

A few thoughts:

1. I don't think we need to recommend using the t3 stack, there's not a need to reach for that for purpose of this example
2. IMO any NextJS/Solid/etc documentation page should just show how to embed a vanilla ExcaliburJS game inside of a component, like what you have for the Entry.tsx file. For most people just getting the game to load is often the obstacle they hit (dealing with SSR and all that jazz).
3. Beyond getting the game to load, the philosophies behind using component logic for UI is really a matter of opinion and I don't feel comfortable pushing any particular way as "the" way. I'd feel better with a community examples repo to reference as a "if you're interested in using React for your game UI or logic, please check out these examples" or something.

My concern is if, for example, many people start using this utils.ts and then we are expected to have the answers for how to use it for all kinds of game logic. I don't think we we can properly support them when they ask for help, and it might be a best if we pose it as a community example for how you could go about this.

[Dryspell]

My concern is if, for example, many people start using this utils.ts and then we are expected to have the answers for how to use it for all kinds of game logic. I don't think we we can properly support them when they ask for help, and it might be a best if we pose it as a community example for how you could go about this.

So with regards to this, I agree for the most part but I also expect that without a way indicated to trigger react re-renders automatically / in a managed fashion, we might be getting a lot of questions about how to trigger React to rerender and this feels like a way to head those off. React won't trigger the rerenders as Excalibur values change and most React devs coming in to Excalibur without this info... well I expect they will either have to do the research and discovery that I did, give up, or ask the question. TBH I don't trust how much experience most React devs have, feels like a lot of new people coming into the space. Definitely am willing to do whatever you guys recommend though, I am but a lowly contributor :D

[mattjennings]

but I also expect that without a way indicated to trigger react re-renders automatically / in a managed fashion, we might be getting a lot of questions about how to trigger React to rerender and this feels like a way to head those off

This is what worries me because the devil truly is in the details there. react-three-fiber even has a whole page of pitfalls to warn about. I wonder if it might be best to explain at a high level of how to communicate from excalibur into a reactive framework so that people know what they're getting into. I actually wonder if that might be the better angle here - a post on how to use a modern web framework for UI in your game?

We have had people who just need to throw in their Excalibur game into a NextJS site or whatever, so that could still be worth covering, but I'm not certain it's worth trying to maintain a post for every major framework. I kind of like the idea of having a post like you've written that's focused just on bridging communication between Excalibur and a modern framework (I'd pick 1, like Solid, because it at least comes with reactive state management out of the box)

[Dryspell]

Maybe offer a warning in the docs page that updating UI elements every frame could have performance implications? I certainly understand the weirdness of coming to React and being like ok you're inventing a new signal here for what...? I certainly suspect there's a better way to implement the whole idea of this custom signal. Like perhaps using excalibur's $observable? I tried briefly to override the setter for Actor.pos so that upon setting it, it re-rendered the UI that I was looking to re-render (namely health bars above the units). But it felt more awkward / hackish to me so I opted against it. Also I switched to Solid more immediately due to the expected performance gains / premature optimization.

[eonarheim]

@Dryspell I haven't forgotten about this! I'm slowly working down my list

[Dryspell]

@Dryspell I haven't forgotten about this! I'm slowly working down my list

No worries! I've been on a long break from Excalibur taking a look at Unity ECS and understanding Websockets better, trying to see what it would be like to implement a request/response framework over websockets. Definitely let me know if you have other ideas or changes that you'd like me to make

[github-actions]

This PR hasn't had any recent activity lately and is being marked as stale automatically.

[chrisk-7777]

A bit late to the party, but the Next docs are really written Dryspell!

I do agree with @mattjennings regarding the amount of direction about bridging the two though.

04-using-nextjs.mdx feels like it contains two distinct, but related, parts:

• (a) How to embed Excalibur in a Next/React app
• (b) How to use React as the UI for Excalibur

I think the docs should go as far as (a). Which is approximately up to the ## Using ExcaliburJS with React line in the PR.

(b) is more related to this section in the docs I believe. But even just within the React space, there are quite a few ways to glue the two together and its hard to prescribe the most idiomatic Excalibur + React patterns. Even just browsing through discussions and the Discord there are quite a few discussions on approach.

A well written blog post, which covers the signals, render cycles, vdom, etc, would be amazing to see though. You could then really get into that nitty gritty

[github-actions]

This PR hasn't had any recent activity lately and is being marked as stale automatically.