feat(types): improve partial-autocomplete and type inference

[M0hammedImran]

Summary

Update types with partial-autocomplete and value type for better type inference.

Description for the changelog

Update types.ts with (string & {}) union.
Other info

[tbouffard]

This is a rework of #256 that looks promising.
I hope to have time to take a look at it before next Wednesday. If I haven't reviewed it by then, feel free to ping me in the comments.
😸

[tbouffard]

@M0hammedImran Thanks for your contribution.

I directly committed to the branch to introduce StyleArrayValue and StyleShapeValue types, as the ArrayValue and the ShapeValue types are for built-in/core values provided by maxGraph according to the JSDoc.
I'm not very happy with the names of the new types, so if you have better names, please suggest them. 😄

[M0hammedImran]

@tbouffard, I have noticed an inconsistency in JSDoc and type here types.ts.

If I read the JSdoc the allowed type is boolean but the actual type used a ENUM DIRECTION.
Please help me understand.

[M0hammedImran]

@tbouffard, I have also noticed there are enums in Constants files. I think we can change it to Object with as const and reduce redundant type.
For example, the DIRECTION enum in Constants.ts can become.

export const DIRECTION = {
  NORTH: 'north',
  SOUTH: 'south',
  EAST: 'east',
  WEST: 'west',
} as const;

And, DirectionValue in types.ts will become.

type Direction = typeof DIRECTION;
export type DirectionValue = Direction[keyof Direction];

The type would remain the same.

Of course, I also realize that there are other files where we might have to make some changes, but I think it's worth it.
Let me know what you think of this.

[tbouffard]

@M0hammedImran thanks for the update.

About DIRECTION, yes this is something that could be changed but this is a larger subject as it applies to a lot of enum. See #205.
I suggest to handle this in a dedicated PR to be able to first merge the work already done here.
We should probably discuss about the enum in #205 first to find a convenient solution. Related fixes/improvements will probably introduce breaking changes.
What do you think about this way of doing?

[tbouffard]

@tbouffard, I have noticed an inconsistency in JSDoc and type here types.ts.

If I read the JSdoc the allowed type is boolean but the actual type used a ENUM DIRECTION. Please help me understand.

Yes this seems to be a error introduced during the migration from mxGraph to maxGraph. This has probably been introduced in b51504d when the style configuration switched from a string to a dedicated object.

In mxGraph, this was a boolean: https://github.com/jgraph/mxgraph/blob/v4.2.2/javascript/src/js/util/mxUtils.js#L2250
I suggest to fix it in a dedicated PR as this will introduce a breaking change and we need to check if it is used in Stories.

[M0hammedImran]

@M0hammedImran thanks for the update.

About DIRECTION, yes this is something that could be changed but this is a larger subject as it applies to a lot of enum. See #205. I suggest to handle this in a dedicated PR to be able to first merge the work already done here. We should probably discuss about the enum in #205 first to find a convenient solution. Related fixes/improvements will probably introduce breaking changes. What do you think about this way of doing?

Yes, I think it would be wise to create a dedicated PR.

[tbouffard]

LGTM
As discussed in comments, there are other types to improved. This will done later.