You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can probably rely on peer-deps to handle React imports, but anything that relies on a PIXI import most likely needs to exist within pixi-react-components to maximize compatibility (since the PIXI import API has changed considerably between versions).
At first glance it would seem that pixi-react-components should be thin and pixi-react should be fat, but it likely needs to be the other way around. pixi-react will pretty much expose only the PixiComponent custom component API and possibly some utils.
Virtually everything else will come from pixi-react-components bar the React Reconciler, which comes from pixi-react-fiber.
The React Reconciler also needs configuration, although most is static, createElement depends on TYPES_INJECTED which will be stored in pixi-react but filled up in pixi-react-components.
Proposed Usage
In a user's app they should setup pixi-react something like this:
The configuration function would look something like this:
functionconfigurePixiReact({
configurePixiReactComponents,
configurePixiReactFiber,}){// PixiComponent updates TYPES_INJECTED (or new name since all will be), but this can basically be private and not// allow dupes?// invariant, PixiComponent, CHILDREN and TYPES_INJECTED come from pixi-react// getTextureFromProps also lives inside pixi-react-components even if not exportedconst{TYPES,
createRoot,
render,
unmountComponentAtNode,
Stage,
applyDefaultProps,
AppProvider,
AppConsumer,
AppContext,
useTick,
useApp,
withPixiApp,
withFilters,
eventHandlers,}=configurePixiReactComponents({
invariant,
PixiComponent,});// All of the reconciler is basically static, except createElement which depends on TYPES_INJECTED, this configure step// basically just makes createElement and then wires everything upconstPixiFiber=configurePixiReactFiber({CHILDREN,// updated to include pixi-react-components by configurePixiReactComponents, should we pass this around explicitly?TYPES_INJECTED,
invariant,
applyDefaultProps,});return{// From pixi-react
PixiComponent,// From pixi-react-componentsTYPES,
createRoot,
render,
unmountComponentAtNode,
Stage,
AppProvider,
AppConsumer,
AppContext,
useTick,
useApp,
applyDefaultProps,// These could come from pixi-react, should they tie to PIXI or React version?
withPixiApp,
withFilters,
eventHandlers,// From pixi-react-fiber
PixiFiber,};}
The text was updated successfully, but these errors were encountered:
@Zyie once we release this I think perhaps we should write a note about what we officially support? We can obviously encourage users to write whatever pixi component packages they need for whichever versions of PIXI, but the combinations could get complicated quickly.
So far we've talked about supporting React 17+ and PIXI 6+, does that mean we support:
React 17 + PIXI 6
React 18 + PIXI 6
React 17 + PIXI 7
React 18 + PIXI 7
Combinations could obviously get complex quickly especially as more versions are released in the future.
I'm wondering whether on top of the user injectable API I've proposed above, we should also provide pre-configured pixi-react version(s) packaged as a single module. So for example @pixi/reactv8.0.0 becomes a wrapper for the above API including React 18 and PIXI 7?
@Zyie once we release this I think perhaps we should write a note about what we officially support? We can obviously encourage users to write whatever pixi component packages they need for whichever versions of PIXI, but the combinations could get complicated quickly.
So far we've talked about supporting React 17+ and PIXI 6+, does that mean we support:
React 17 + PIXI 6
React 18 + PIXI 6
React 17 + PIXI 7
React 18 + PIXI 7
Yeah i think these should be what we support
So for example @pixi/reactv8.0.0 becomes a wrapper for the above API including React 18 and PIXI 7?
Yeah this is a good approach. Makes it very simple for whoever wants the latest version
Spec
Rough map of current source to new modules
Notes
peer-deps
to handle React imports, but anything that relies on a PIXI import most likely needs to exist withinpixi-react-components
to maximize compatibility (since the PIXI import API has changed considerably between versions).pixi-react-components
should be thin andpixi-react
should be fat, but it likely needs to be the other way around.pixi-react
will pretty much expose only thePixiComponent
custom component API and possibly some utils.pixi-react-components
bar the React Reconciler, which comes frompixi-react-fiber
.createElement
depends onTYPES_INJECTED
which will be stored inpixi-react
but filled up inpixi-react-components
.Proposed Usage
In a user's app they should setup pixi-react something like this:
Implementation
The configuration function would look something like this:
The text was updated successfully, but these errors were encountered: