Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove deprecated life cycle methods (move towards functional components) #28

Open
JasonBristol opened this issue Sep 1, 2019 · 5 comments

Comments

@JasonBristol
Copy link
Contributor

JasonBristol commented Sep 1, 2019

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.

@bberak
Copy link
Owner

bberak commented Sep 2, 2019

Thanks @JasonBristol. In that case, let's leave this issue open as a discussion on moving towards functional components.

@bberak bberak changed the title Remove deprecated life cycle methods Remove deprecated life cycle methods (move towards functional components) Sep 2, 2019
@tomazbracic
Copy link

+1 for functional components and hooks

@bberak
Copy link
Owner

bberak commented Oct 26, 2019

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.

@JasonBristol
Copy link
Contributor Author

JasonBristol commented Oct 26, 2019

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.

@bberak
Copy link
Owner

bberak commented Oct 27, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants