How to type data for Animation.Parse in Babylon.js?

Questions
1

Hi, I have a small script with physics enabled, where I create and record animations. Here’s an example how I save animation for json:

interface AnimationKeys {
    frame: number;
    values: number[];
}

const diceRotationAnimation = {
    name: "diceShakeRotation",
    property: "rotationQuaternion",
    framePerSecond: this.fps,
    dataType: Animation.ANIMATIONTYPE_QUATERNION,
    loopBehavior: Animation.ANIMATIONLOOPMODE_CONSTANT,
    keys: diceRotationKeys, // this is AnimationKeys
};

Later, I use the Animation.Parse function to process the animation:
https://doc.babylonjs.com/typedoc/classes/BABYLON.Animation#Parse

And code is working

The problem:

When I save the animation object as shown above, I don’t have strict types to validate the structure. This makes the code type-unsafe. For instance, if I accidentally miss a required property, the error will only show up at runtime.

Question:

Does Babylon.js provide a built-in type (like an interface or a class) that I can use to type objects like diceRotationAnimation? Or do I need to manually create my own type for this purpose?

Thanks for your help!

2

Yes.

3

yes like permanent solution or like workaround?)
because, it is problem. how can I understand which params I should to extract?

4

We do not provide the typings associated with our serialized formats but I like the idea. Do you want to try and do a PR on the animation class ?

At least you could then reuse the exported type in your app.

This would replace the any we are relying on here
image

5

I think I read that the Parse format changes over time. Either it was said, or I inferred that it shouldn’t be relied on to be stable from release to release. Does incorporating strict typing change that? What happens when a new element is added to the Parse definition and doesn’t exist in a user’s JSON?

I think the goal would be that the parsing silently defaults the unspecified property. Aside from making sure to not increase the maintenance burden of developers, this seems like a decent (and expansive) change.

But who am I to talk about expansive: I’m working on incorporating most of CSS into the GUI?? Holy smokes, CSS is huge!

2 Likes
6

Yep, I can try

If Parse changes and breaks from release to release, then the entire code relying on it will break as well with each new release.

Strict typing helps catch such issues at the compilation stage, providing an early warning system for breaking changes (not in realtime)

Don’t worry, you can also described it in the type definition as optional or deprecated fields, making the behavior explicit and reducing ambiguity for developers.