Reviewing files that changed from the base of the PR and between 97ec7d0 and 7072a23.

• packages/core/src/types.ts (2 hunks)
• packages/core/src/view/cell/CellRenderer.ts (2 hunks)
• packages/core/src/view/cell/register-shapes.ts (2 hunks)
• packages/core/src/view/handler/ElbowEdgeHandler.ts (2 hunks)
• packages/core/src/view/style/StyleRegistry.ts (2 hunks)
• packages/core/src/view/style/Stylesheet.ts (2 hunks)
• packages/core/src/view/style/marker/EdgeMarkerRegistry.ts (3 hunks)
• packages/core/src/view/style/marker/edge-markers.ts (5 hunks)
• packages/core/src/view/style/register.ts (4 hunks)
• packages/js-example-without-defaults/src/index.js (1 hunks)
• packages/ts-example-without-defaults/src/main.ts (1 hunks)
• packages/ts-example/src/main.ts (1 hunks)

• GitHub Check: build
• GitHub Check: build (windows-2022)
• GitHub Check: build (macos-14)
• GitHub Check: build (ubuntu-22.04)

packages/core/src/types.ts (3)

561-563: Documentation improvement for perimeter property

The documentation now more clearly specifies that PerimeterFunction types can be builtin functions from the Perimeter namespace, improving developer understanding.

---

563-564: Better type safety with PerimeterValue reference

Documentation now refers to PerimeterValue instead of PERIMETER, aligning with the move to type-safe values instead of enum constants.

---

1273-1279: Improved type definition with separate MarkerFunction type

The refactoring separates the marker function type from the factory function type by:

1. Changing MarkerFactoryFunction to return the new MarkerFunction type
2. Creating a dedicated MarkerFunction type alias

This provides better type clarity and IDE support when working with markers.

packages/ts-example-without-defaults/src/main.ts (1)

54-54: Replaced enum constant with string literal for edge style

Updated the edge style reference from using constants.EDGESTYLE.ORTHOGONAL to the string literal 'orthogonalEdgeStyle', improving type safety and IDE autocompletion support.

packages/js-example-without-defaults/src/index.js (1)

54-54: Replaced enum constant with string literal for edge style

Updated the edge style reference from using constants.EDGESTYLE.ORTHOGONAL to the string literal 'orthogonalEdgeStyle', providing consistency with the TypeScript examples and aligning with the type-safe approach.

packages/ts-example/src/main.ts (1)

81-81: Replaced enum constant with string literal for edge style

Updated the edge style reference from using constants.EDGESTYLE.ORTHOGONAL to the string literal 'orthogonalEdgeStyle' in the legacy insertEdge method, ensuring consistent implementation of the type-safe approach throughout the codebase.

packages/core/src/view/style/Stylesheet.ts (1)

19-19: String literal usage aligned with TypeScript type safety improvements

Replacing the imported ARROW constant with a string literal for the edge arrow style is a good change. This aligns with the PR objective of replacing enum constants with type-safe name values, which will provide better IDE support through autocompletion.

The change is part of the planned removal of ARROW, EDGESTYLE, and PERIMETER enums mentioned in the PR description.

Also applies to: 85-85

packages/core/src/view/cell/CellRenderer.ts (1)

49-49: Improved type safety for shape registration

Changing the key parameter type from string to StyleShapeValue provides better type safety and IDE autocompletion. This is a great improvement that aligns with the PR objectives of enhancing developer experience when registering built-in elements.

The StyleShapeValue type restricts the possible values to predefined shape types while still allowing for extensibility through the string union type.

Also applies to: 159-159

packages/core/src/view/cell/register-shapes.ts (1)

18-18: Enhanced type safety for shape registration array

Updating the type of the shapesToRegister array from [string, ShapeConstructor][] to [ShapeValue, ShapeConstructor][] improves type safety. This change ensures that only valid predefined shape values from the ShapeValue type can be registered.

This change is consistent with the updated parameter type in CellRenderer.registerShape() and contributes to better IDE autocompletion support.

Also applies to: 48-48

packages/core/src/view/style/marker/edge-markers.ts (3)

24-27: Good refactoring: Extracted type check predicates

Creating dedicated helper functions for type checking is a good refactoring. These predicate functions make the code more readable and maintainable by centralizing the logic for checking arrow types.

The new functions also work with the StyleArrowValue type, which aligns with the PR's goal of improving type safety.

---

67-67: Improved readability by using type predicates

Replacing direct string comparisons with the isClassicOrClassicThin function improves code readability and maintainability. If the definition of what constitutes a "classic" arrow changes in the future, you'll only need to update it in one place.

Also applies to: 79-79

---

226-226: Improved readability with the isDiamond predicate

Using the isDiamond function here improves readability and ensures consistency in how diamond markers are detected throughout the code.

packages/core/src/view/handler/ElbowEdgeHandler.ts (2)

20-20: Good removal of the EDGESTYLE import

The EDGESTYLE constant is no longer needed as the code now uses string literals for edge styles, aligning with the PR objective to replace enum constants with type-safe names.

---

114-116: Good refactoring to use string literals

The change from EDGESTYLE.TOPTOBOTTOM and EDGESTYLE.ELBOW constants to string literals 'topToBottomEdgeStyle' and 'elbowEdgeStyle' improves type safety and IDE support while maintaining the same functionality.

packages/core/src/view/style/StyleRegistry.ts (2)

19-19: Good addition of specific types

Adding explicit imports for EdgeStyleValue and PerimeterValue types enhances type safety and improves IDE support for these specialized string values.

---

37-37: Excellent type refinement

Updating the parameter type from generic string to the more specific union type PerimeterValue | EdgeStyleValue | string improves IDE guidance through better autocompletion support while maintaining compatibility with existing code.

packages/core/src/view/style/marker/EdgeMarkerRegistry.ts (3)

19-23: Good addition of explicit types

Adding the MarkerFunction type import and organizing imports with proper structure improves code clarity and type safety.

---

45-46: Great parameter naming and type refinement

Renaming from funct to factory makes the parameter name more descriptive, and changing the type from string to StyleArrowValue enhances type safety and IDE autocomplete support.

---

63-63: Good explicit return type

Adding the explicit return type MarkerFunction | null improves type safety and makes the method signature more self-documenting.

packages/core/src/view/style/register.ts (5)

18-18: Good refactoring of imports

Updating imports to use named exports from './builtin-style-elements' makes the code more maintainable and aligns with the type-safe approach being implemented.

---

22-28: Good type imports

Adding explicit imports for type aliases (ArrowValue, EdgeStyleValue, PerimeterValue) improves code consistency and supports the enhanced type safety throughout the file.

---

41-49: Excellent type-safe edge style registration

Refactoring to use explicit type annotation with EdgeStyleValue and string literals instead of constants provides better IDE guidance and type safety, making it easier for developers to register edge styles correctly.

---

70-75: Excellent type-safe perimeter registration

Similar to the edge styles, this change replaces constant values with typed string literals for perimeters, providing better IDE autocompletion and type checking.

---

112-121: Excellent type-safe marker registration

Refactoring to use ArrowValue type and string literals for markers while also using the EdgeMarker class methods improves type safety and IDE support, making the code more maintainable.