RFP: How should shape-specific APIs be exposed?

[codynova]

Some functions are specific to a shape class - for example, Cannon's ConvexPolyhedron shape has a transformAllPoints function which can be used to adjust the alignment axes for the shape. This function is useful for orienting physics bodies and meshes into the same axes.

I'm requesting proposals on how use-cannon should expose these shape-specific APIs? We can continue to add all available APIs to the object returned from useBody, but some (many?) of those will not actually be valid depending on which hook you are using.

Maybe we could have a generic API object with methods which are valid for all physics bodies, and spread spread that into a second API object that's generated based on the type of the shape (and maybe a third based on the body type if necessary)?

[stockhuman]

This is a great question - is the invalidity of various API for particular shapes a faux-pas, even if that invalidity makes perfect sense?

In the future I'd like to integrate V-HACD in a way that matches #6, which is probably better suited to the generated, shape-specific approach.

[codynova]

I would say it is a faux-pas. We would need to guard against users attempting to call functions which don't exist on certain classes to provide a remotely sane dev experience, and even then you'd get misleading intellisense. I think the generated approach makes more sense from a TypeScript perspective as well.

And now I'm off topic but wow, V-HACD looks incredible.

[codynova]

Related to #28

[drcmda]

each hook could bring its own types, and makeapi could maybe take some kind of injection callback so that hooks can add their specific apis?

[drcmda]

function useBody(
  type: BodyShapeType, 
  fn: BodyFn, 
  inject: (...) => any
  argFn: ArgFn, deps: any[] = []): Api {
    ...
    function makeApi(index?: number): WorkerApi {
      return {
        // Specific api
        ...inject(index, post, getUUID, makeVec),

[codynova]

That sounds pretty ideal to me...