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

Use isThing rather than instanceof; add typedefs and tests #55

Merged
merged 8 commits into from
Jan 12, 2023

Conversation

ChristopherChudzicki
Copy link
Collaborator

In #49 we discussed two changes:

  1. simpling ThreeJS imports
  2. swapping instanceof checks for isColor, isVector2, etc, that ThreeJS uses.

#53 implemented (1), this PR does (2).

Additionally, this PR contains type definitions for more properties. Yay.

@@ -121,18 +144,60 @@ export type TypeGenerators = {
object: any;
timestamp: any;

vec2: any;
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is technically a breaking change, at least for TS users, I suppose.

When I initially added TS definitions, I only added full definitions for some properties, because I was still trying to understand the codebase (and still am, I suppose). I decided to leave untyped stuff as any rather than unknown, which would have been the safer but more annoying approach.

Anyway, improvements to static typing are always going to be somewhat breaking, so I don't think this warrants a major version bump.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm fine with that, we can go semver once we get the README tidied up with all of this extra dev info and with updates on the changes we've made to the project.

Copy link
Collaborator

@sritchie sritchie left a comment

Choose a reason for hiding this comment

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

This looks great, merge as you please, I just had a couple of questions inline.

*/
type ColorDescription = string | Color | number | number[];

type Vec2Like = number | number[] | Vector2;
Copy link
Collaborator

Choose a reason for hiding this comment

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

what's the meaning of the number type for these? Do we interpret that as the first coordinate and fill in zeros for the rest? I get it for color above, but not yet for the Vec*Like types.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Basically, for vec2/3/4, supplying a single number behaves like supplying an array with one item. And if the array has fewer items than expected, default values are used for the remaining items.

Take for example <cartesian /> nodes... One of their traits is view3. The view3 trait defines several properties, [including scale](https://github.com/unconed/mathbox/blob/master/src/primitives/types/traits.ts#L40:

// the Type for <cartesian>'s "scale" property, as defined in traits.js
scale: Types.vec3(1, 1, 1)

But imagine it was scale: Types.vec3(a, b, c)... Then:

cartesian.set("scale", x) // --> [x, b, c]
cartesian.set("scale", [x, y]) // --> [x, y, c]
cartesian.set("scale", [x, y, z]) // --> [x, y, z]
cartesian.set("scale", new THREE.Vector3(x)) // --> [x, 0, 0] ... the 0, 0 defaults are set by THREE

I'm not trying to suggest that supplying a single number is actually a good idea... just documenting the current type validation system it seems intended.

@@ -121,18 +144,60 @@ export type TypeGenerators = {
object: any;
timestamp: any;

vec2: any;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm fine with that, we can go semver once we get the README tidied up with all of this extra dev info and with updates on the changes we've made to the project.

ivec3: any;
vec4: any;
ivec4: any;
vec2(x?: number, y?: number): Type<Vec2Like, Vector2>;
Copy link
Collaborator

Choose a reason for hiding this comment

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

do we default values to 0?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It depends. There are multiple properties with type vec2, and each can have different defaults. Calling Types.vec2(x, y) is more like creating a validation instance, with instance-specific defaults.

Using view3 as an example again (which Caresian and some other nodes use):

// traits.js
view3: {
  position: Types.vec3(),
  quaternion: Types.quat(),
  rotation: Types.vec3(),
  scale: Types.vec3(1, 1, 1),
  eulerOrder: Types.swizzle("xyz"),
},

Calling Types.vec3(a,b,c) creates a sort of schema that (1) provides a default value of (a, b, c) and (2) provides a validator function.
So:

  • position's default value is (0, 0, 0) and when you set position, any unspecified components default to 0.
  • scale's default value is (1, 1, 1) and when you set scale, any unspecified components are set to 1.

* but the defaults are usually not used. (They are when passing an array,
* but not when passing a Vector4 instance).
*
* In pratice this probably doesn't really matter, since Mathbox doesn't
Copy link
Collaborator

Choose a reason for hiding this comment

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

practice*

).toEqual(new Color(0.3,0.4,0.5));
expect(onInvalid).not.toHaveBeenCalled();

// Numbers are interpretted as hex
Copy link
Collaborator

Choose a reason for hiding this comment

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

interpreted*

/**
* This seems like a bug. `Types.quat(...)` accepts default values for xyzw,
* but the defaults are usually not used. (They are when passing an array,
* but not when passing a Vector4 instance).
Copy link
Collaborator

Choose a reason for hiding this comment

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

that does seem like a bug! where does that happen? Can we make a ticket at least if there's some spot where the vector4 and array behaviors differ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I reworded the comment a little. I think it's not currently observable, but would be easy to fix.

@sritchie sritchie linked an issue Jan 11, 2023 that may be closed by this pull request
@ChristopherChudzicki ChristopherChudzicki merged commit 558ffc2 into master Jan 12, 2023
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.

Bug when using mathbox + THREE.Color in a bundle
2 participants