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

Create API layer between hooks and cannon web worker #343

Merged
merged 1 commit into from
Feb 15, 2022

Conversation

isaac-mason
Copy link
Member

@isaac-mason isaac-mason commented Feb 12, 2022

@vercel
Copy link

vercel bot commented Feb 12, 2022

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/pmndrs/use-cannon/Ev4hdUedpSPXZfunE2P2YP3FfrZg
✅ Preview: https://use-cannon-git-fork-isaac-mason-worker-api-pmndrs.vercel.app

@isaac-mason isaac-mason marked this pull request as draft February 12, 2022 02:30
@isaac-mason isaac-mason changed the title [WIP] Create API layer between hooks and cannon web worker Create API layer between hooks and cannon web worker Feb 12, 2022
CannonWebWorker,
DefaultContactMaterial,
DisableConstraintMessage,
DisableConstraintMotorMessage,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like we could have a single type that we import instead of each individually named message.

I'd like to remove the need for WithoutOp as well.

Maybe we can do something like:
CannonMessageBody<'disableConstraintMotor'>
or
CannonMessageMap['disableConstraintMotor']

Copy link
Member Author

@isaac-mason isaac-mason Feb 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure! I can get rid of all the imports and WithoutOp by putting an omit in something like CannonMessageBody, sounds good.

I'll update the PR with this & the rebase shortly. Should have time to do this tomorrow 🙂

@bjornstar
Copy link
Member

I'm actually ok with everything and moving forward from here. Does it seem like a usable api for the worker?

@isaac-mason
Copy link
Member Author

isaac-mason commented Feb 12, 2022

Great! Thanks for taking a look.

I think the worker API as it is now is largely good for building out the non-react package. There are a couple of things we may want to add/change as we go. One thing that comes to mind is - if we're building the other package to mirror cannon-es syntax/usage as we discussed in the issue, we may add addShape and removeShape worker ops for bodies?

But it's probably best to look at making those changes in small chunks as we build out that package.

For now, wrapping the current worker as-is sounds good to me 🙂

I'll update the PR to address your comments & rebase shortly.

Motivation: This is a step towards moving worker logic into a separate package
@isaac-mason
Copy link
Member Author

@bjornstar I've rebased now & addressed your comments!

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

Successfully merging this pull request may close these issues.

2 participants