Open JasonBristol opened 5 years ago
Thanks @JasonBristol. In that case, let's leave this issue open as a discussion on moving towards functional components.
+1 for functional components and hooks
Just some food for thought:
If we move to functional components, we'll need a way/technique to maintain backward compatibility for the current imperative API. For example, it would be great (essential?) if we can still call some useful methods on the GameEngine:
this.refs.gameEngine.dispatch("Some event to send to the systems");
And
this.refs.gameEngine.swap({ Some new entities });
I think this can be achieved with the imperative handle hook but I haven't used that one yet.
This goes a little beyond just converting to FCs and hooks, but what are your thoughts on something like this?
const { swap, dispatch, ...otherMethods } = useGameEngine();
Where GameEngine
is now a provider with a defined context that we could consume and interact with from anywhere.
I haven't given this approach a huge amount of thought so I am not sure if it is bulletproof, but if we were to tackle converting the engine to use hooks we have a nice opportunity to expose hooks to the api
This would potentially break backwards compatibility, if we were okay with that i.e. produce this as v1 or v2 (not sure if we are using semantic versioning) this could provide a nice hook to allow other components to interact with the engine.
Cool @JasonBristol, lets give this approach some more thought. I've recently started using hooks for my day job - so am slowly familiarizing myself.
Ideally we can preserve backwards compatibility - but I think that might be impossible. Yeah, we're using semantive versioning - so moving to v2 might have to be the way to go.
Currently deprecated lifecycle hooks will be removed in react 17. PR #27 adds the
UNSAFE_
tag to remove warnings, but we should consider converting to functional components for react 17.