Help understanding the intended usage patterns of pixi-react

[RickeyWard]

Hello! I'm quite experienced in react for web applications, and I've used JavaScript game engines before. But while looking at some community/youtube tutorials about using pixi-react it's not clear to me what the libraries intentions are for how to be used. And the docs don't provided complex enough examples.

I can easily get things working but I'm having trouble understanding the intentions.

Is the goal for pixi-react to create all the privatives and add them to the stage for you and then you just use the ticker as an onupdate game loop like you would a normal pixijs scene ignoring react's reactive pipeline? or is the goal for you to use reacts reactive pipeline for state/rerender behavior to have a data first approach to state->view mapping?

All the tutorials I've come across seem to be the former, where once the primitive exists you forget its in react and just manipulate the object directly and get a reference to it via a react ref.

What is the actual recommended pattern?

-Thanks

[thejustinwalsh]

The goal of @pixi/react is to provide a maintainable and extensible library for working with pixi.js using React.

Is the goal for pixi-react to create all the privatives and add them to the stage for you and then you just use the ticker as an onupdate game loop like you would a normal pixijs scene ignoring react's reactive pipeline? or is the goal for you to use reacts reactive pipeline for state/rerender behavior to have a data first approach to state->view mapping?

Components with high frequency updates may choose to use the useTick hook and imparitivly update the component, while components that are reactive to user interaction via a mouse click or run side effects on mount will use react hooks to manage state updates. You may even choose to do both in a single component.

What is the actual recommended pattern?

@pixi/react is not perscriptive and there are many patterns that are used when developing applications, much like react itself. Best practices are not even totally agreed upon in the discord channel with developers sharing the pros/cons of the approaches they use for solving specific problems.

I follow some general guidelines in my thought process when working in @pixi/react:

• Motion is usually easiest to reason about and update in a useTick callback.
• Events are usually state updates that are best handled with reactivity.
• If I start with a useTick and find myself building a state machine, I extract that logic to reactive state updates.
• If I start with useState and useEffect and find myself building an effect loop, I switch to useTick.

All the general best practices of avoiding unneccesary react re-renders apply, like using a state manager, avoiding context, debouncing, and memoizing components. Performance is king in games and simulations and re-renders in react can be pure overhead, so if you find your application is slowing down and your profiler is spending too much time in react, taking a ref and updating the component imperativly might be the last thing you need to boost that frame rate again.

[RickeyWard]

Thanks for the reply!

That is a complicated tightrope to have to think about.

Is it practical to just use the pixi-react component to bootstrap the pixi app into a react app and do the rest entirely in vanilla pixijs? Or would I be better served just writing my own simple pixi-wrapper component?

it seems like I can drop any pixijs example body into <Application onInit={ /* example code */ } /> and it just works

[thejustinwalsh]

You can also just use the whole library reactively and not worry about any of the above.

Without knowing what you are building and what your constraints are it is hard to give general advice. Build it like a react app, and if something is slow, use the guidelines above to optimize and speed it up.

If you are making Vampire Survivors, you might spend time optimizing with @pixi/react performant patterns.
If you are making Balatro, you might be fine with pure reactivity using react hooks only.

Make it work, make it right, make it fast.

[thejustinwalsh]

Is it practical to just use the pixi-react component to bootstrap the pixi app into a react app and do the rest entirely in vanilla pixijs? Or would I be better served just writing my own simple pixi-wrapper component?

it seems like I can drop any pixijs example body into <Application onInit={ /* example code */ } /> and it just works

I would rather use pixi.js in an effect in a standard react app over the above. @pixi/react is running it's own reconciler which is separate from react-dom and it seems like a lot of extra stuff to bring along to only use the Application component and not lean on the rest of the library.

You had mentioned in your original post that the docs do not provide enough complex examples. What examples would you like to see to help you to understand how to use @pixi/react effectively?