Expose rendering errors (e.g. loggedErr) in a public API

[solyane2002]

Description of new feature

I would like Cytoscape.js to expose rendering-time errors, such as those currently tracked internally via _private.rscratch.loggedErr, through a public and supported API — for example via edge.error()

Motivation for new feature

When using curveStyle: "segments", if the edge has an invalid configuration (e.g., missing segment points or malformed control points), Cytoscape.js internally flags it with loggedErr = true to avoid repeating console warnings.

In my case, I need to return an error and reject the graph properly with a friendly message in the UI.

Here is the function I implemented for now:

export const checkForInvalidEdgeWarning = (cyCore: Core): Error | null => {
  const invalidEdgeIds: string[] = [];
  cyCore.edges('[curveStyle = "segments"]').forEach((edge) => {
    if (edge[0]._private.rscratch.loggedErr) {
      invalidEdgeIds.push(edge.id());
    }
  });

  if (invalidEdgeIds.length > 0) {
    return new Error(`invalid edge(s) detected on segments curve style  (${invalidEdgeIds.join(', ')})`);
  }
  return null;
};

However, this information is only available via a private internal structure (edge._private.rscratch.loggedErr), which:

• Is not part of the public API and may break across versions
• Is not safe to use in TypeScript without casting to any
• Prevents detecting errors programmatically in a clean and maintainable way

Thanks for your great work on Cytoscape.js!
Let me know if you'd consider a PR, or if there's a recommended alternative way to detect such rendering errors.

For reviewers

Reviewers should ensure that the following tasks are carried out for incorporated issues:

• Ensure that the reporter has adequately described their idea. If not, elicit more information about the use case. You should iteratively build a spec together.
• Ensure that the issue is a good fit for the core library. Some things are best done in extensions (e.g. UI-related features that aren't style-related). Some things are best done by app authors themselves -- instead of in Cytoscape libraries.
• The issue has been associated with a corresponding milestone.
• The commits have been incorporated into the unstable branch via pull request. The corresponding pull request is cross-referenced.

[maxkfranz]

What about checking with the current, public API?

E.g.

// helpers
const isWellDefined = num => num != null && Number.isFinite(num);
const isWellDefinedPoint = pt => pt != null && isWellDefined(pt.x) && isWellDefined(pt.y);
const isValidSegmentEdge = edge => edge.segmentPoints().every(isWellDefinedPoint);

// invalid edges collection
const invalidEdges = cy.edges().difference(isValidSegmentEdge); // assuming all edges are curve-style:segments

[solyane2002]

Thanks for your reply and the suggestion.

I had already considered a similar validation approach manually, but unfortunately it doesn’t fully solve the problem for the following reasons:

• .difference() issue
  

  Using cy.edges().difference(isValidSegmentEdge) doesn’t work directly, since .difference() expects a Collection as argument, not a filtering function. Trying to call it this way causes an error like:
  toRemove.has is not a function.
  To make it work, I’d need to first manually build a Collection of invalid edges — but at that point, I’m already duplicating the logic anyway.

• Manual checks are incomplete and error-prone
  

  While I could replicate the internal validation logic with something like segmentPoints().every(...), this assumes I know all the exact validation rules Cytoscape.js performs.
  However, the library might validate more subtle edge cases internally — especially if those rules evolve over time. For example, I don’t want to miss future validations added for other curve styles, invalid data formats, etc.

• Avoiding duplication and coupling
  

  Relying on private properties like _private.rscratch.loggedErr is not ideal either, but it currently reflects the actual internal validation result of Cytoscape’s rendering logic. This is much more robust than trying to mirror that logic externally.

What I’d really like is for Cytoscape.js to expose this internal flag — loggedErr or equivalent — via a safe, public API like edge.hasRenderingError() or edge.renderingError(), so that application developers can react accordingly without depending on unstable internals.

[maxkfranz]

Hi, @solyane2002. Good to hear back from you.

Using cy.edges().difference(isValidSegmentEdge) doesn’t work directly, since .difference() expects a Collection as argument, not a filtering function. Trying to call it this way causes an error like

I didn't really test my code. I just wanted to communicate the main point. You could do:

const invalidEdges = cy.edges().difference(cy.edges(isValidSegmentEdge)); // assuming all edges are curve-style:segments

// or 

const invalidEdges = cy.edges(edge => ! isValidSegmentEdge(edge));

However, the library might validate more subtle edge cases internally — especially if those rules evolve over time. For example, I don’t want to miss future validations added for other curve styles, invalid data formats, etc.

The only thing the library can do in any case of invalid points is to not have any points for the edge. So the approach I mentioned would work e.g. for beziers by checking the control points instead of the segments points for bezier edges.

If you want a more general approach for different edge types, I suppose you could check that the midpoint is defined. An edge, regardless of type, should not have a midpoint defined if the edge is invalid.

You could write a custom extension with a few lines for something like this:

cytoscape('collection', 'validPoints', function(){
  const isWellDefined = num => num != null && Number.isFinite(num);
  const isWellDefinedPoint = pt => pt != null && isWellDefined(pt.x) && isWellDefined(pt.y);

  return this.isNode() || isWellDefinedPoint(this.midpoint()).
});