DEV Community: Rajeshwari Pandinagarajan

7 Signs of Technical Debt in Vibe Coding and How to Refactor

Rajeshwari Pandinagarajan — Fri, 06 Nov 2026 03:56:16 +0000

TL;DR: Vibe coding helps developers build features quickly, but repeated AI-generated changes can leave behind duplicated logic, inconsistent patterns, and code that is difficult to maintain. Learn seven warning signs of technical debt, how to audit a feature across its changes, and a practical approach for deciding what to refactor.

Introduction

A developer asks an AI coding assistant to create a function. Another prompt adds validation, and a third handles an edge case. Within a short time, the feature is implemented, the code compiles, and the tests pass.

Everything appears to be working as expected. But then comes a small change.

You revisit the code and find duplicated logic, business rules scattered across files, and components with unnecessary dependencies. What seemed like a straightforward implementation has become more difficult to modify.

This is one of the challenges of AI-assisted development. When generated code is accepted without considering the overall application architecture, quick solutions can gradually introduce technical debt.

Let’s explore why this happens, how to identify the warning signs, and what developers can do to keep AI-generated code maintainable.

What is Vibe Coding Technical Debt?

Vibe coding is an informal way of building software through iterative conversations with AI. You describe what you want, an AI assistant generates or modifies code, and you refine the result through further prompts.

Technical debt refers to design or implementation decisions that make software harder or more expensive to maintain, extend, or modify later. A solution may work today but still make future changes more difficult. Technical debt is not necessarily a bug, although debt and defects can exist together.

AI-generated technical debt can be difficult to notice because the code may run and tests may pass, even when coverage is incomplete. An assistant may also suggest a solution that works for the immediate request but duplicates an existing implementation or conflicts with a project convention.

The important distinction is between a change that works for the current task and a change that fits the application as a whole.

How it happens

Imagine asking an AI assistant to add authentication to an endpoint. It adds a token check at the beginning of the function. The endpoint works.

The next week, you need rate limiting. Another conditional is added. Then, you request logging, guest-user handling, and an administrator exception.

After several changes, the endpoint may contain authentication, authorization, rate limiting, logging, and business logic in one function. Testing becomes more complicated, and each new change has more responsibilities to consider.

The pattern can spread across the application. Different endpoints may end up with slightly different authentication implementations, duplicated rate-limiting logic, and inconsistent administrator checks. Each change may work in isolation, while the accumulation makes the code harder to maintain.

Before vs. After vs. Refactored

Here’s a simplified JavaScript example of how an endpoint can become a patchwork of unrelated responsibilities.

Before: Clean service function

async function getUserProfile(userId) {
  return await db.users.findById(userId);
}

After: Patchwork function

async function getUserProfile(userId, token, req) {
  if (!token) throw new Error('No token');

  // Decoding does not verify the token signature.
  const decoded = jwt.decode(token);
  if (!decoded) throw new Error('Invalid token');

  const isAdmin = await db.admins.exists(decoded.id);

  if (!isAdmin) {
    const recentCalls = await redis.get(`calls:${decoded.id}`);
    if (recentCalls > 100) throw new Error('Rate limited');
  }

  logger.info(`Fetching profile for ${decoded.id}`);

  if (isAdmin && req?.guestAccess) {
    // Special handling for guest administrators
  }

  return await db.users.findById(userId);
}

This example intentionally shows responsibilities accumulating in one function. It is not a recommended authentication implementation. In particular, jwt.decode() only decodes a token; it does not verify its signature. Decoding alone must not be used to authenticate a request.

After refactoring: Separate responsibilities

// Authentication middleware verifies the token.
function authMiddleware(req, res, next) {
  const token = req.headers.authorization?.replace(/^Bearer\s+/, '');

  if (!token) {
    return res.status(401).json({ error: 'Authentication required' });
  }

  try {
    req.user = jwt.verify(token, process.env.JWT_SECRET);
    return next();
  } catch {
    return res.status(401).json({ error: 'Invalid or expired token' });
  }
}

// The service is configured separately from the route handler.
const rateLimiter = new RateLimitService();

// Rate limiting is handled separately.
async function rateLimitMiddleware(req, res, next) {
  try {
    const allowed = await rateLimiter.isAllowed(req.user.id);

    if (!allowed) {
      return res.status(429).json({ error: 'Rate limited' });
    }

    return next();
  } catch (error) {
    return next(error);
  }
}

// The endpoint focuses on retrieving the signed-in user's profile.
async function getUserProfile(req, res, next) {
  try {
    const user = await db.users.findById(req.user.id);

    if (!user) {
      return res.status(404).json({ error: 'User not found' });
    }

    logger.info(`Profile accessed by ${req.user.id}`);
    return res.json(user);
  } catch (error) {
    return next(error);
  }
}

// Example Express route; middleware order matters.
router.get('/profile', authMiddleware, rateLimitMiddleware, getUserProfile);

This is an illustrative Express-style example. It assumes that the JWT secret, database, logger, and rate-limiter service are configured, and that the application has appropriate error-handling middleware. The route applies authentication before rate limiting and the endpoint. Applications that allow access to other users’ profiles also need an explicit authorization check.

The improvement is not simply fewer lines. Each part now has a clear responsibility, and the route makes the request flow visible. That makes the code easier to review and gives developers clearer places to test authentication, rate limiting, and profile retrieval independently.

7 signs your vibe-coded project is becoming patchwork

These signs are prompts for investigation, not a formal scoring standard. One sign alone does not prove that a codebase has serious debt. Look for recurring patterns and their impact.

Sign	Why it matters	What to do
Same files changed repeatedly	Fixes may be addressing symptoms rather than causes.	Review file history and investigate recurring changes.
Logic duplicated across files	Copies can drift and behave differently.	Consider shared middleware, helpers, or services.
Growing conditionals	Complex branching is harder to understand and test.	Clarify rules and consider a suitable policy or role-based approach.
Dependency sprawl	Overlapping libraries add maintenance overhead.	Check existing dependencies before adding another.
Mixed architecture patterns	Inconsistent approaches make the codebase harder to understand.	Document and follow suitable project patterns.
Tests changed to pass code	Test changes can hide defects if expectations are weakened.	Change tests only when requirements or expected behavior change.
Code with unclear purpose	Unknown dependencies make changes risky.	Trace the reason for the code and document important decisions.

1. You keep changing the same files

Check your Git history. If the same files appear repeatedly in commits during a sprint, you may be patching symptoms instead of solving the underlying problem.

What to do: Review the changes together. Are they all fixing different symptoms of the same design issue? Treat repeated changes as a signal to investigate, not as a fixed numerical threshold.

2. The same logic exists in multiple places

Authentication logic may appear separately in users.js, posts.js, and comments.js, with slightly different implementations. When the rule changes, every copy needs to be updated.

What to do: Identify genuinely shared behavior and consider extracting it into middleware, a helper, or a service. Avoid creating an abstraction when the code only looks similar but serves different purposes.

3. Conditionals keep growing

Nested conditions can accumulate for administrators, moderators, premium users, guests, and other special cases. As the logic grows, it becomes harder to understand which rules apply and how they interact.

What to do: Clarify the business rules first. Consider role-based access control (RBAC) when permissions are organized around roles, or a policy-based approach when access depends on more detailed conditions. Choose an approach that fits the application.

4. Dependencies pile up

An AI assistant may suggest a new library without knowing that the project already has a dependency for the same purpose. A codebase might gradually include multiple utility or date-handling libraries.

What to do: Check whether an existing dependency or built-in capability already meets the requirement. Consider maintenance status, compatibility, security, and bundle-size impact where relevant before adding another package.

5. Architecture is all over the place

One part of an application may use MVC, another may use functional handlers, and another may introduce classes for similar responsibilities. Data access may also vary without a clear reason.

What to do: Document the patterns the team wants to follow, including routing, data access, authentication, error handling, and testing. Share relevant guidance when prompting AI assistants.

6. Tests get changed to make code pass

Imagine a test expects verified to be true. It fails, and an AI assistant changes the expectation to false. The test now passes, but the implementation may still be wrong.

What to do: Understand why the test failed before changing it. Fix the implementation when it does not meet the requirement. Change a test when expected behavior has genuinely changed, not just to make a failing test pass.

7. Nobody knows why code exists

Comments such as “Not sure if needed” or “Don’t remove, breaks prod” are warning signs when they do not explain the reason behind the code.

What to do: Trace the code to the requirement or decision that introduced it. Document important constraints and why a particular approach was chosen. Confirm that code is no longer needed before removing it.

A practical audit: Follow one feature across its changes

A useful way to find AI-related technical debt is to audit one feature rather than asking an assistant to review the entire repository and accepting a long list of generic suggestions.

For example, choose the profile endpoint from the earlier code sample. Review the feature in this order:

Trace the change history: Use git log --oneline -- path/to/profile-file.js to see commits that changed the file. Open the relevant diffs and identify which requirements led to each change.
Map the responsibilities: List what the endpoint currently handles: token validation, permission checks, rate limiting, logging, database access, and response formatting.
Find duplicated behavior: Search for other endpoints that implement the same authentication or rate-limiting rules. Compare the behavior, not just the names of the functions.
Check the tests: Find tests for valid tokens, missing or invalid tokens, rate limits, missing users, and unexpected database errors. Confirm that the tests reflect the intended behavior.
Review dependencies and assumptions: Check whether the endpoint uses existing project services and conventions. Identify any new package or special-case rule that needs justification.
Record findings before changing code: Separate confirmed defects from maintainability concerns and possible improvements.

A simple audit note could look like this:

Finding	Evidence to collect	Suggested next step
Authentication repeated in several routes	Compare route handlers and middleware	Consolidate only if the behavior and security requirements match.
Rate limiting mixed with profile logic	Trace the endpoint and its tests	Move rate limiting into dedicated middleware or a service.
Admin exception is unclear	Find the requirement and authorization rule	Confirm the rule with the product or security owner before changing it.
Missing failure-path tests	Review existing test cases	Add tests for invalid tokens, rate limits, and missing users.

This is where the audit becomes more valuable than a generic code review: every finding is tied to a specific file, behavior, or requirement. Do not refactor solely because an AI tool labels something as complex. First confirm that the issue exists and that the proposed change preserves the required behavior.

Why AI-assisted development can accumulate debt

AI coding assistants can generate useful local changes, but they may not always account for the whole system. Several factors contribute to this risk:

Incomplete context: An assistant may not have access to every relevant file, architectural decision, or business rule. Even when it can inspect a repository, it may not understand why an existing pattern was chosen.
Local task focus: A generated change may address the prompt without considering every system-wide effect. Developers still need to review maintainability, consistency, and integration.
Limited continuity: Context can vary by tool, configuration, and session. Without project-level guidance, later suggestions may not follow earlier decisions.
Patches hide root causes: When a patch fixes an immediate symptom, the underlying design issue may remain.
Fast iteration: AI makes code generation faster. If review and refactoring do not receive enough attention, changes can accumulate faster than the team can evaluate them.

The lesson is not that AI-generated code is inherently worse than human-written code. Both need review. The important question is whether each change meets the same standards for correctness, security, consistency, and maintainability.

A six-step approach to stop the patchwork

Use this approach when a change touches an area that has become difficult to maintain.

Step 1: PAUSE

Stop coding and step back. Ask yourself:

Am I solving the right problem?
Is this a band-aid for a bigger issue?
Have I changed this area repeatedly?
Did the AI assistant have the architectural context needed for this change?

Step 2: INSPECT

Open your Git diff and review the recent history of the files you changed. Then ask:

Do I understand every important line that was added?
Is the change consistent with the rest of the codebase?
Would I approve this implementation in a code review?
Does it solve the underlying problem or only address a symptom?

Step 3: TEST

Check whether tests cover the changed behavior:

What about edge cases?
Does error handling work as expected?
What happens with missing, invalid, or unexpected input?
Could this change affect another part of the application?

You can ask AI to suggest missing test cases, but review those suggestions against the actual requirements. Tests should verify expected behavior, not simply make the implementation pass.

Step 4: REFACTOR

Improve the structure where necessary:

Pull genuinely duplicated code into shared functions.
Simplify deeply nested conditionals.
Group related responsibilities together.
Simplify unnecessarily complex function signatures.
Remove unused code or dependencies only after confirming they are not needed.
Add comments that explain important decisions.

Ask AI to suggest a behavior-preserving refactor and explain the proposed changes. Review the result and run relevant tests before accepting it.

Step 5: DOCUMENT

Write down why a decision was made, not just what the code does. For example, explain why the team chose a simple discount implementation instead of introducing a rule-engine library, and what future change would justify revisiting that decision.

Step 6: CONTINUE

Once the change is reviewed, tested, and easier to maintain, continue building. The goal is to address complexity before it becomes expensive to manage.

Should you patch, refactor, or rebuild?

Not every issue needs a large refactor. Choose the smallest change that safely addresses the underlying problem.

Situation	Better next step	Why
A small, isolated defect with a clear cause	Patch	A focused fix is appropriate when it does not add another workaround or break an established pattern.
The same logic is repeated or responsibilities are mixed	Refactor	Improve the structure while preserving the required behavior.
Several features depend on an unclear or unsuitable design	Assess a broader redesign	First map dependencies, risks, migration effort, and a safe transition path.
A prototype is not yet production code	Keep it lightweight, but set a review point	Avoid premature architecture, but do not let experimental code become production code without review.

A rebuild should not be the automatic response to a messy codebase. It can introduce new risks and may recreate the same problems if the underlying requirements and design decisions are not addressed. Prefer incremental refactoring when it can safely improve the system.

Team practices for AI-assisted development

Technical debt is also a team concern. Shared practices help keep generated code consistent:

Share architecture guidance: Document the project’s routing, data access, authentication, error-handling, and testing conventions.
Maintain reviewed prompts: Keep useful prompts for common tasks, but update them when project patterns change.
Review high-impact changes carefully: Give additional attention to authentication, authorization, data access, and new dependencies.
Use AI as a review aid: Ask it to identify edge cases, duplication, and possible inconsistencies. Developers remain responsible for verifying the findings.

Quick audit checklist

Use these questions during a code review or maintenance session:

Is the same logic implemented in multiple files?
Are some files repeatedly changed to address related issues?
Are there several different ways to handle the same operation, such as authentication, logging, or validation?
Are multiple libraries being used for essentially the same purpose?
Is important conditional logic deeply nested or difficult to follow?
Are there comments such as “Don’t touch this” without an explanation?
Does the team struggle to explain why an important piece of code exists?

Use the answers to identify areas for investigation, not to produce a formal technical-debt score. Prioritize findings by their impact on security, correctness, maintainability, and the effort required to fix them.

AI prompt template: Architecture-first approach

Use this template to give an AI assistant context before asking it to implement a change.

TASK: [Describe what you want to build or change.]

PROJECT CONTEXT:
[Relevant files, architecture, existing patterns, and constraints.]

PATTERNS:
[Authentication, logging, data access, error handling, and testing conventions.]

CONSTRAINTS:
- Reuse existing abstractions where appropriate.
- Avoid unnecessary dependencies.
- Preserve existing behavior unless requirements say otherwise.
- Include relevant tests.
- Explain assumptions and trade-offs.

BEFORE IMPLEMENTING:
1. Identify relevant existing code.
2. Explain which patterns or abstractions can be reused.
3. Identify possible edge cases and risks.
4. Present an implementation plan.

THEN:
Implement the approved approach and summarize the changes and tests.

Review the proposed plan and generated code before using them. Providing context improves the quality of the discussion, but it does not guarantee that generated code is correct.

Frequently Asked Questions

1. What if my codebase is already a patchwork? Is it too late to fix?

No. Start with the file or feature causing the most maintenance problems. Review its behavior, add or improve tests, extract duplicated logic where appropriate, and clarify its responsibilities. Work in manageable steps rather than trying to restructure the entire application at once.

2. Are there situations where quick AI patches are fine?

Yes. Quick patches can be appropriate for prototypes, throwaway experiments, or low-risk changes when the trade-offs are understood. Before a prototype becomes production code, review its architecture, security, and test coverage.

3. How do I convince my team to make time for refactoring?

Track examples of repeated bug fixes, slow code reviews, and time spent understanding complex areas. Explain how addressing a specific source of complexity could reduce future maintenance effort. Start with a focused improvement and use the result to demonstrate its value.

4. Does using AI automatically create technical debt?

No. AI-generated code can be maintainable when it is reviewed, tested, and aligned with the project’s requirements and architecture. Technical debt can result from human-written code as well. The important factor is how changes are evaluated and maintained.

Keep the speed, lose the patchwork

Vibe coding is not inherently flawed. AI assistants can help developers explore ideas and build features faster. Problems arise when rapid iteration happens without enough attention to architecture, testing, and maintainability.

The seven warning signs help identify a codebase that is becoming harder to change. The practical audit shows how to trace a concern back to specific code and supporting evidence. The six-step approach helps developers inspect, test, refactor, and document changes, while the patch-or-refactor guide helps determine the right level of response.

Start with one feature or file that repeatedly causes maintenance work. Trace its history, verify the behavior, and prioritize the issues that have the greatest impact. Use AI to analyze and review code, but keep developers responsible for understanding and approving the changes.

Build faster with AI while keeping your codebase maintainable.

Related blogs

How to Validate PDF Digital Signatures in JavaScript with Timestamps and Long-Term Validation (LTV)

Rajeshwari Pandinagarajan — Wed, 04 Nov 2026 15:30:00 +0000

TL;DR: Need to verify signed PDFs long after signing? Learn how to digitally sign PDFs, add trusted timestamps, enable Long-Term Validation (LTV), and validate individual or multiple signatures using the Syncfusion JavaScript PDF Library.

A digital signature helps verify who signed a PDF and whether the document has changed since signing. But how can you validate that signature months or even years later, especially when the signing certificate has expired or revocation information is no longer available?

Trusted timestamps and Long-Term Validation (LTV) information help preserve the evidence needed for future signature verification.

With the 2026 Volume 3 release, Syncfusion® added digital signature validation and Long-Term Validation (LTV) capabilities in its JavaScript PDF Library.

In this guide, you’ll learn how to:

Sign PDF documents using a digital certificate.
Add a trusted timestamp from a Time Stamping Authority (TSA).
Enable Long-Term Validation (LTV).
Validate individual and multiple signatures.
Interpret validation results correctly.

Important: A trusted timestamp and LTV information can help preserve the evidence needed to validate a PDF signature in the future. However, successful long-term validation still depends on the signature’s integrity, the available certificate and revocation evidence, the certificate chain, and the trust policies used by the validating application. LTV improves future validation readiness but does not guarantee indefinite validation under all circumstances.

What the new PDF validation capability enables

The new validation capabilities allow developers to:

Verify whether a signed document has been altered after signing.
Validate certificate chains used by signatures.
Inspect trusted timestamp information.
Check certificate revocation status using OCSP and CRL evidence.
Validate a specific signature field.
Validate multiple signatures in a single PDF document.
Support processes that require long-term signature verification.

These capabilities are especially useful in document management, finance, legal, healthcare, government, and compliance-focused applications where document integrity must be preserved over time.

Digitally sign a PDF in JavaScript

Digital signatures help verify a PDF document’s authenticity, confirm the identity of the signer, and detect whether the document has been altered after signing. By applying a certificate-based digital signature, you can establish trust in electronic documents and support secure document processing.

Using the Syncfusion JavaScript PDF Library, you can digitally sign both newly created and existing PDF documents with industry-standard certificates.

Prerequisites

Before you begin, ensure you have the following:

A valid digital certificate (.PFX or .P12) containing the private key.
The certificate password.
A PDF document to sign, or a new PDF document to create.
The Syncfusion JavaScript PDF Library.

Security consideration: Never hardcode PFX passwords, private keys, or certificate files in browser-delivered JavaScript. Private keys are sensitive cryptographic assets and should be protected appropriately. For high-security environments, consider server-side signing or a managed digital-signing service rather than exposing signing credentials to client applications.

Once your certificate and PDF document are ready, you can sign the document by creating a signature field, applying a digital signature, and saving the signed PDF.

Steps to digitally sign a PDF

Step 1: Create or load a PDF document

Create a new document or load an existing PDF, depending on your use case. The document acts as the container for the digital signature and related form fields.

Step 2: Create a signature field

Add a PdfSignatureField to the document. This field defines where the signature information will be stored and displayed within the PDF.

Step 3: Create and apply a digital signature

Load the PFX certificate and create a PdfSignature object using the certificate and password. You can also specify the cryptographic standard and hashing algorithm used to generate the signature.

Step 4: Add the signature field and save the document

After applying the signature, add the signature field to the PDF form and save the document. The resulting PDF contains a verifiable digital signature that can later be validated for integrity and authenticity.

The following example creates a new PDF document, adds a signature field, and applies a digital signature using a PFX certificate and the SHA-256 hashing algorithm:

// Create the document
var document = new ej.pdf.PdfDocument();
// Get the first page of the document
var page = document.addPage();
// Access the PDF form
var form = document.form;
// Create a new signature field
var field = new ej.pdf.PdfSignatureField(page, 'Signature', {x: 10, y: 10, width: 100, height: 50});
// Create a new signature using PFX data and private key
var sign = ej.pdf.PdfSignature.create(certData, password, {cryptographicStandard: ej.pdf.CryptographicStandard.cms, digestAlgorithm: ej.pdf.DigestAlgorithm.sha256});
// Set the signature to the field
field.setSignature(sign);
// Add the field to the PDF form
form.add(field);
// Draw the logo in the signature appearance 
const signatureAppearance = field.getAppearance(); 
const signatureImage = new PdfBitmap(logo); 
signatureAppearance.normal.graphics.drawImage(signatureImage, { 
    x: 20, 
    y: 20, 
    width: 120, 
    height: 50 
}); 
// Save the document
document.save('output.pdf');
// Destroy the document
document.destroy();

Adding a digital signature to a PDF

Note: In this example, certData represents the PFX certificate bytes and password is the certificate password. These values should be securely loaded through your application’s credential management process rather than embedded directly in source code.

For additional signing scenarios, including signing existing PDFs and advanced signature configuration options, explore the digital signature demo and refer to the API documentation.

Add a trusted timestamp to a PDF signature

A timestamp records when a document was signed through a trusted Time Stamping Authority (TSA). It provides evidence of the signing time and helps support future signature verification.

To add a timestamp, provide a timestamp callback when creating the digital signature. The callback returns the TSA response, which is embedded into the signature during the save operation.

The following example shows how to add a timestamp to a digitally signed PDF document.

// Create a timestamp callback
async function timestampCallback(request) {
    // Implement timestamp response logic here
    return { response: new Uint8Array() }; // Placeholder return
}
// Create a new signature using PFX data, private key and callback function for timestamp
const signature = ej.pdf.PdfSignature.create(certData, password, { cryptographicStandard: ej.pdf.CryptographicStandard.cms, digestAlgorithm: ej.pdf.DigestAlgorithm.sha256 }, timestampCallback);
field.setSignature(signature);
// Save the document
await document.saveAsync('output.pdf');

Adding a timestamp to a digitally signed PDF document

Note: This example demonstrates the callback contract only. Your application must send the timestamp request to a trusted Time Stamping Authority (TSA) and return the TSA response bytes.

Why use saveAsync()?

When timestamping is enabled, the library must communicate with an external TSA service. Because the operation is asynchronous, use await document.saveAsync() to ensure that the timestamp response is received and embedded before the PDF is generated.

For a complete timestamp integration example, refer to the digital signature documentation.

Enhance PDF signature validation with Long-Term Validation (LTV)

A trusted timestamp helps establish when a document was signed, but long-term verification often requires additional evidence. If certificate revocation services become unavailable, validators may not be able to retrieve the information needed to determine whether the signing certificate was trusted at the time of signing.

Long-Term Validation (LTV) helps address this challenge by embedding certificate and revocation information directly into the PDF.

To enable LTV:

Sign and save the PDF.
Reload the signed document.
Retrieve the signature.
Call the enableLTV() method and provide revocation responses through the callback.

The following code example demonstrates how to enable LTV for a signed PDF document.

// Load the signed PDF document
const document = new ej.pdf.PdfDocument(data);
// Get the signature field
const field = document.form.fieldAt(0);
// Retrieve the PDF signature
const signature = field.getSignature();
// Retrieve the OCSP or CRL response requested by the library
var longTermValidationCallback = async function (url, requestBytes) {
    // Send requestBytes to the approved URL and return the actual response bytes
    return { response: revocationResponse };
};
// Enable LTV for the created signature
var ltvEnabled = await signature.enableLTV(longTermValidationCallback);
// Save the LTV-enabled PDF document
document.save('output.pdf');

Note: This callback must return the actual OCSP or CRL response bytes requested by the library. Network communication, authentication, retry logic, and error handling should be implemented by your application.

After you enable LTV, the PDF contains additional validation information that can support future verification and archival processes.

For complete LTV examples and implementation guidance, refer to the LTV documentation.

Validate PDF signatures

Once a signed PDF contains timestamp and optional LTV information, the next step is validation. Validation helps determine whether the document has been modified after signing and whether the associated certificates, timestamps, and revocation information remain trustworthy.

The Syncfusion JavaScript PDF Library supports validation for both individual signatures and multiple signatures contained within a PDF document.

During validation, the library can verify document modifications, certificate chains, timestamp information, revocation status through OCSP or CRL data, and multiple signatures available in the document.

Validating PDF signatures using the Syncfusion JavaScript PDF Library

Validation prerequisites

Before validating signatures, prepare the following:

documentData: The PDF document bytes to validate.
certificateData: Trusted root or intermediate certificate data used to establish trust.
passwords: Optional passwords used only when validating encrypted PDFs or password-protected processes.

Providing a certificate does not automatically establish trust. Validation depends on whether a complete and trusted certificate chain can be successfully built according to your organization’s trust requirements.

Validate a single signature

To validate an individual signature, retrieve the associated signature field and call the validateSignature() method. The validation process checks whether the document has been modified after signing and evaluates certificate trust, timestamp validity, and revocation status based on the specified validation options.

The following example validates a single signature using trusted certificate information:

// Load the signed PDF document.
const document = new ej.pdf.PdfDocument(documentData);
// Get the first signature field from the form.
const field = document.form.fieldAt(0);
// Configure the signature validation options.
const options = {
    trustedCertificates: [certificateData],
    passwords: ['syncfusion']
};
// Validate the signature.
const validationResult = field.validateSignature(options);
// Check the validation result.
console.log('Signature name: ' + validationResult.signatureName);
console.log('Signature valid: ' + validationResult.isSignatureValid);
console.log('Signature status: ' + validationResult.signatureStatus);
console.log('Document modified: ' + validationResult.isDocumentModified);
console.log('Revocation result: ', validationResult.revocationResult);
// Destroy the document and release its resources.
document. Destroy();

The returned validation result contains details about signature validity, document integrity, certificate-chain validation, timestamp verification, and revocation checks.

Include the passwords option only when validating encrypted PDFs or processes that require password-protected content.

Note: Explore the digital signature validation demo to see the validation process in action and review the validation results returned by the API.

Validate multiple signatures in a PDF

When a PDF contains multiple signatures, validate them collectively using the validateSignatures() method. The method evaluates every signature field in the document and returns both overall and signature-specific validation results.

The following example validates all signatures in a PDF document:

// Load the PDF document that contains multiple signatures.
const document = new ej.pdf.PdfDocument(documentData);
// Configure the validation options.
const options = {
    trustedCertificates: [certificateData]
    passwords: ['syncfusion']
};
// Validate all signatures in the PDF document.
const validationResult = document.form.validateSignatures(options);
if (validationResult.results !== null &&
    validationResult.results !== undefined) {
    console.log(
        'Number of validated signatures: ' +
        validationResult.results.length
    );
    validationResult.results.forEach((result) => {
        console.log(
            `${result.signatureName}: ${result.isSignatureValid}`
        );
    });
}
// Determine whether all signatures are valid.
if (validationResult.isValid) {
    console.log('All signatures in the PDF document are valid.');
} else {
    console.log('One or more signatures in the PDF document are invalid.');
}

The validationResult.isValid property indicates the overall validation outcome for the document. Review the entries in validationResult.results to inspect the status of each individual signature.

Note: For additional validation scenarios, review the digital signature validation demo and documentation. They include examples covering certificate validation, revocation checking, timestamp verification, and multi-signature validation processes.

Understanding validation results

The validationResult.isValid property represents the overall validation outcome based on the validation options you supplied.

However, developers should also review the individual entries in validationResult.results, since each signature may have different validation outcomes for:

Certificate trust.
Timestamp verification.
Revocation status.
Certificate-chain validation.
Document integrity.

Reviewing individual validation results provides a more complete assessment than relying only on a single Boolean value. It also helps you make more informed trust decisions when processing signed PDF documents.

Build a trusted PDF signing and validation process

Now that we’ve covered signing, timestamping, LTV, and validation individually, let’s see how they fit together in a complete process.

Creating a trusted PDF process involves more than simply applying a digital signature. To ensure long-term document reliability, follow this recommended sequence:

Sign the PDF to establish document authenticity and integrity.
Add a trusted timestamp to record when the document was signed.
Enable LTV to embed revocation information required for future verification.
Validate the signature before accepting, sharing, or archiving the document.

Following this process helps preserve the evidence needed to validate signed PDF documents after certificate expiration or when external revocation services are unavailable.

Recommended process

Step 1: Sign the PDF using PdfSignature.create().
Step 2: Add a timestamp using a TSA callback and saveAsync().
Step 3: Reload the signed document and enable LTV using enableLTV().
Step 4: Validate the signature using validateSignature() or validateSignatures().

In production environments, these four stages represent the complete trust lifecycle of a signed PDF document. Each stage adds verification evidence that helps preserve trust beyond the initial signing event.

By combining these stages, you can build secure and reliable PDF signing processes for contracts, compliance documents, business records, and other long-term digital documents.

Frequently Asked Questions

Why is a basic digital signature not enough for long-term PDF trust?

Certificates can expire, and revocation information may not always be available in the future. Without a trusted timestamp and Long-Term Validation (LTV), signature validation may lack the evidence required to verify the document over time.

What does a signature timestamp prove?

A trusted Time Stamping Authority (TSA) provides evidence of when a document was signed. This timestamp can help establish that the signature existed at a particular time and support verification against the signing certificate’s validity period.

What is LTV in PDF digital signatures?

Long-Term Validation (LTV) embeds revocation information, such as OCSP and CRL responses, directly into the PDF. This helps support signature validation even when external revocation services are unavailable.

Does the JavaScript PDF Library support PDF digital signing?

Yes. The Syncfusion JavaScript PDF Library supports certificate-based digital signatures for both new and existing PDF documents through the PdfSignature and PdfSignatureField classes.

Can LTV and timestamps be used together?

Yes. You can add a timestamp when creating the digital signature and then enable Long-Term Validation (LTV) after signing to support long-term signature verification.

How are signatures validated with the library?

Use signature.validate() to validate an individual signature and document.form.validateSignatures() to validate all signatures in a PDF document.

Conclusion

Digital signatures help verify the authenticity and integrity of PDF documents, but trusted timestamps, Long-Term Validation (LTV), and signature validation are essential for maintaining trust over time.

In this blog, we explored how to sign PDFs in JavaScript, add trusted timestamps, enable LTV, and validate digital signatures using the Syncfusion JavaScript PDF Library. By combining these capabilities, you can build secure PDF processes that remain verifiable long after documents are signed.

Ready to get started? Explore the Syncfusion JavaScript PDF Library and add digital signing and validation capabilities to your applications.

If you’re an existing Syncfusion user, download the latest version from the license and downloads page. New users can start with a free 30-day trial.

For questions or assistance, reach out through the support forum, support portal, or feedback portal.

Related blogs

TypeScript 7.0 Migration Guide: Performance, Compatibility, and Upgrade Steps

Rajeshwari Pandinagarajan — Mon, 19 Oct 2026 14:03:35 +0000

TL;DR: TypeScript 7.0 introduces a native compiler written in Go, with Microsoft’s benchmarks reporting 7.7× to 11.9× faster full builds across five selected projects. This guide covers compiler API compatibility, framework and editor support, tsconfig.json changes, and practical benchmarking steps to help you evaluate the upgrade for your project.

Slow TypeScript builds can delay development, particularly in large applications and monorepos. TypeScript 7.0 introduces a native compiler written in Go, with substantial speed improvements in Microsoft’s published benchmarks.

However, upgrading involves more than measuring build speed. TypeScript 7.0 changes the compiler implementation, configuration defaults, and language-server tooling, which may affect existing frameworks and development tools.

This guide explains the performance results, compatibility checks, configuration changes, and benchmarking steps you should complete before upgrading.

1. What changes in TypeScript 7.0?

The biggest change is the compiler itself. Earlier versions of TypeScript used a compiler written in TypeScript that ran on JavaScript runtimes such as Node.js. TypeScript 7.0 introduces a native implementation written in Go.

The new implementation combines native execution with parallel processing. This allows the compiler to make better use of modern hardware for tasks such as parsing, type-checking, and generating output.

Here are the main changes to consider before upgrading.

Area	What changes?	What should you check?
Build performance	Native compilation and parallel processing can reduce build times.	Benchmark your own project.
Compiler API	TypeScript 7.0 does not include the programmatic compiler API available in TypeScript 6.0.	Check tools that import TypeScript directly.
Configuration	TypeScript 6.0 defaults and certain deprecations carry forward.	Review `tsconfig.json`.
Framework integrations	Some integrations still depend on TypeScript 6.0.	Check your framework's current guidance.
Editor support	TypeScript 7.0 uses a new language server based on the Language Server Protocol (LSP).	Test autocomplete, diagnostics, navigation, and refactoring.
JavaScript and `JSDoc`	Some legacy options and syntax patterns have changed.	Test JavaScript projects that rely on `JSDoc` type-checking.

For the complete list of changes, refer to Microsoft’s TypeScript 7.0 announcement.

2. How much faster is TypeScript 7.0?

Microsoft published the following full-build measurements comparing TypeScript 6.0 and TypeScript 7.0 on selected open-source projects.

Project	TypeScript 6.0	TypeScript 7.0	Reported speedup
VS Code	125.7 seconds	10.6 seconds	11.9×
Sentry	139.8 seconds	15.7 seconds	8.9×
Bluesky	24.3 seconds	2.8 seconds	8.7×
Playwright	12.8 seconds	1.47 seconds	8.7×
tldraw	11.2 seconds	1.46 seconds	7.7×

Source: Microsoft’s TypeScript 7.0 announcement.

These results show substantial full-build improvements in Microsoft’s selected benchmark projects, along with lower aggregate memory consumption across those builds. However, these are benchmark results and should not be treated as guaranteed improvements for every project, direct measurements of incremental rebuilds, editor responsiveness, or complete application build times. Actual results depend on factors such as project structure, hardware, build configuration, caching, and how much of your development process is spent on TypeScript compilation.

When is upgrading worth evaluating?

TypeScript 7.0 is worth testing if:

Your full builds take a long time.
Your monorepo contains many interdependent packages.
Type-checking takes a significant share of your CI time.
Your editor struggles with a large codebase.
Developers frequently wait for compilation after making changes.

If your project already builds quickly, the performance benefit may be less important than compatibility and maintenance. Measure your current setup before deciding.

3. Check compiler API and tooling compatibility

Before upgrading, check whether your project or its dependencies use the TypeScript compiler API.

TypeScript 7.0 does not currently expose the programmatic compiler API available in TypeScript 6.0. Tools that inspect types, modify abstract syntax trees (ASTs), or perform custom transformations may therefore need to continue using the TypeScript 6.0 compatibility package until a suitable API is available.

Check for dependencies such as:

Custom AST transformers.
Code-generation tools that inspect TypeScript types.
Tools that call APIs such as ts.createProgram() or ts.createLanguageService().
Linters and framework integrations that depend on the compiler API.

If your project only uses the standard tsc command and its dependencies support TypeScript 7.0, migration may be simpler. Projects that rely on the compiler API need additional compatibility checks before switching.

How to check your dependencies

Start by searching your source files for direct TypeScript imports.

For example, on a system with grep, run:

grep -RIn --include='*.ts' --include='*.js' \
  'from "typescript"' .

Check for CommonJS imports separately:

grep -RIn --include='*.ts' --include='*.js' \
  "require('typescript')" .

You can also search for common compiler API calls:

grep -RIn --include='*.ts' --include='*.js' \
  -E 'ts\.createProgram|ts\.createLanguageService|ts\.getCompilerOptions' .

These commands are a starting point, not a complete dependency audit. They may miss different quote styles, dynamic imports, other file extensions, and dependencies inside installed packages.

For npm projects, also inspect the installed dependency tree:

npm ls typescript
npm explain typescript

These commands help identify direct and transitive TypeScript dependencies, but you should still verify API usage and compatibility with each tool’s documentation.

Also review your package.json, build scripts, framework plugins, and lint configuration.

Which tools should you check?

Tool	What to verify
Standard `tsc` builds	Confirm that compilation works with TypeScript 7.0.
typescript-eslint	Check its currently supported TypeScript version range.
Custom AST transformers	Verify access to the compiler API they require.
Framework language services	Follow the framework's compatibility guidance.
Code generators and AST tools	Test type analysis and generated output.
Editor extensions	Check diagnostics, navigation, autocomplete, and other required features.

For example, the typescript-eslint dependency guide lists the TypeScript versions it supports. Check the current range before upgrading because support changes over time.

A tool may appear to work outside its officially supported version range. That does not mean the combination is supported or that future updates will continue to work.

4. Check framework and editor compatibility

A successful command-line build does not guarantee that your framework tooling or editor will work correctly with TypeScript 7.0.

Microsoft identifies Vue, MDX, Astro, and Svelte projects, along with specialized Angular template checking, as areas where TypeScript 6.0 compatibility may still be required.

Before upgrading, verify the supported TypeScript versions for your framework, language service, editor extensions, and build tools.

Standard TypeScript projects: Test TypeScript 7.0 if your dependencies are compatible.
Angular: You may be able to use TypeScript 7.0 for command-line error checking while retaining TypeScript 6.0 for editor or template tooling. Verify your Angular version and setup.
Vue, Astro, Svelte, and MDX: Check the framework’s official guidance before switching the full toolchain.
Other frameworks and editors: Confirm that the language service and extensions you rely on support your intended setup.

TypeScript 7.0’s new language server uses LSP, which allows editor integrations to communicate with the language service through a standard protocol.

After upgrading, test the editor features your team relies on, including diagnostics, autocomplete, go-to-definition, and refactoring.

For current compatibility details, consult Microsoft’s TypeScript 7.0 announcement.

5. Review your tsconfig.json

TypeScript 7.0 adopts TypeScript 6.0’s defaults and turns certain deprecated options into errors. Projects upgrading directly from TypeScript 5.x may therefore need more preparation than projects already using TypeScript 6.0.

Review these settings carefully.

Setting	What to check
`strict`	Defaults to `true`. Check whether your code is ready for strict type-checking.
`module`	Defaults to `esnext`. Verify that it fits your build setup.
`target`	Defaults to the stable `ECMAScript` version immediately before `esnext`.
`types`	Defaults to an empty array. Add the global type packages your project needs.
`rootDir`	Defaults to the project root. Set it explicitly if your source files live in a subdirectory such as `src`.
`stableTypeOrdering`	Defaults to `true` and can no longer be disabled.
`noUncheckedSideEffectImports`	Defaults to `true`. Check side-effect imports, including imports used for styles or other assets.
`libReplacement`	Defaults to `false`. Check whether your project depends on the previous behavior.
`baseUrl`	No longer supported. Update path mappings to work relative to the project root.
`moduleResolution`	Legacy `node/node10` and classic modes are no longer supported. Review whether `bundler` or `nodenext` fits your project.

Check global type declarations

The types default can affect projects that rely on global declarations from packages such as Node.js and Jest.

For example, you may need to list the required packages explicitly:

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

The exact list depends on your installed type packages and the global declarations your project needs.

Other deprecated settings also require attention. For example, target: "es5" and downlevelIteration are no longer supported. Review the TypeScript 6.0 release notes and the TypeScript 7.0 announcement before upgrading.

What about JavaScript projects using JSDoc?

TypeScript 7.0 also changes how some legacy JavaScript and JSDoc patterns are handled.

If your project uses checkJs, JSDoc annotations, or JavaScript files that rely on TypeScript’s type inference, test those files carefully. Compare the diagnostics before and after upgrading, then update unsupported patterns according to the official migration guidance.

6. Benchmark TypeScript 7.0 in your own repository

The best way to evaluate TypeScript 7.0 is to benchmark it against your current compiler in the same repository and environment.

Measure three scenarios separately:

Clean build: Measures compilation without previously generated TypeScript build outputs.
Incremental rebuild: Measures compilation after a representative source-file change.
Up-to-date build: Measures the time required when no source files have changed.

Also record peak memory usage and total CI build duration where possible. Keep the hardware, configuration, source changes, and cleanup conditions consistent between compiler versions.

Remember that an application build may include bundling, minification, and asset processing beyond TypeScript compilation.

Step 1: Record your current baseline

Before upgrading, record:

Current TypeScript version.
Node.js and package-manager versions.
Relevant tsconfig.json files.
Clean full-build time.
Incremental rebuild time after a source change.
Peak memory usage, if available.
Total CI build duration.

Use the same machine or equivalent CI runners for both compiler versions.

Step 2: Measure a clean build

For a project that uses TypeScript project references, start with:

# Clean outputs managed by TypeScript build mode.
npx tsc --build --clean

# Measure the clean build.
time npx tsc --build

Make sure your cleanup process also accounts for any additional generated files or caches used by your project. This command does not necessarily clear every tool’s cache.

Step 3: Measure an incremental rebuild

After the clean build, make a small, representative change to a TypeScript source file. Then run:

time npx tsc --build

This measures a rebuild after a source change, with the build information from the previous run available. It is more useful for evaluating incremental performance than simply running the build again without changing anything.

If you run the command once more without making any changes, record that separately as an up-to-date build. Do not treat it as an incremental rebuild after a source change.

For Windows PowerShell, you can measure a build with:

Measure-Command { npx tsc --build }

Repeat the same steps with TypeScript 7.0, using the same source change, repository state, and equivalent cleanup conditions.

Step 4: Measure the complete application build separately

Run your normal application build as another measurement:

npm run build

This command may include bundling, minification, asset processing, and other work beyond TypeScript compilation.

For example, if your full application build takes 60 seconds and TypeScript accounts for 30 seconds, a faster compiler will not eliminate the time spent on the remaining build steps.

Step 5: Compare the results

Metric	Current compiler	TypeScript 7.0
Clean full-build time	Measure	Measure
Incremental rebuild after a source change	Measure	Measure
Up-to-date build time	Measure	Measure
Peak memory usage	Measure	Measure
End-to-end CI duration	Measure	Measure
Tests and linting	Record results	Record results
Editor and framework behavior	Evaluate	Evaluate

Run the measurements multiple times and report how you compared them, for example, by using the median of several runs. Keep hardware, configuration, source changes, and cache conditions consistent.

The goal is not to reproduce Microsoft’s benchmark numbers. It is to find out whether TypeScript 7.0 improves the parts of your development process that matter to your team.

7. Tune concurrency only after measuring

TypeScript 7.0 provides experimental options for adjusting parallel processing:

--checkers controls the number of type-checker workers.
--builders controls the number of parallel project-reference builders in build mode.
--singleThreaded disables parallel processing.

Increasing concurrency may reduce build time, but it can also increase memory usage. Because project builders and type-checker workers can operate concurrently, their combined resource requirements matter.

Start with the default settings and benchmark your project first. If tuning is necessary, change one option at a time and compare build time and memory consumption.

Verify the current behavior of these experimental options in Microsoft’s official guidance before adding them to build scripts.

8. Run TypeScript 6.0 and 7.0 side by side when needed

Some projects may need TypeScript 7.0 for command-line compilation while retaining TypeScript 6.0 for tools that depend on its compiler API.

Microsoft provides the @typescript/typescript6 compatibility package for toolchains that still require the TypeScript 6.0 API. This allows teams to evaluate the native compiler without immediately replacing every compiler-dependent tool.

Microsoft documents an npm alias setup such as:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

In this setup, @typescript/native provides the TypeScript 7.0 compiler, while the typescript dependency resolves to the TypeScript 6.0 compatibility package for tools that need its API.

Use a side-by-side setup only when your project requires it. After configuring the package aliases, verify which compiler each tool loads and test builds, linting, editor integration, and CI.

Follow Microsoft’s current installation guidance before applying the configuration to your project.

9. TypeScript 7.0 migration checklist

Use this checklist to plan and validate your upgrade.

Before upgrading

Record the current TypeScript version and build performance.
Audit direct and transitive compiler API dependencies.
Check framework, editor, linter, and transformer compatibility.
Review TypeScript 6.0 configuration changes and deprecated options.
Create a separate branch for migration.

During the upgrade

Install TypeScript 7.0 using the official package instructions.
Update unsupported configuration options.
Run clean builds and incremental rebuilds.
Run tests, linting, and type-checking.
Compare generated output and declaration files where relevant.

Before rollout

Compare build time and memory use against the baseline.
Verify editor diagnostics, navigation, and autocomplete.
Test framework-specific templates and language services.
Validate CI and staging pipelines.
Document any compatibility workarounds for the team.
Define rollback criteria and retain the previous compiler configuration in case of compatibility issues, failing tests, or unexpected build regressions.

Use the checklist alongside the compatibility checks in Sections 3 and 4. Completing the steps helps you identify migration risks before the upgrade reaches your main development environment.

10. Should you upgrade to TypeScript 7.0 now?

Your upgrade decision should depend on two factors: compatibility and measurable performance gains.

Your situation	Recommended approach
Standard CLI compilation, compatible dependencies, and slow builds	Pilot TypeScript 7.0 and measure the results.
Large monorepo with long CI builds	Benchmark full and incremental builds, and validate project-reference builds.
Project already builds quickly	Upgrade when there is a clear performance or maintenance benefit.
Heavy compiler API usage or custom transformers	Verify the compatibility path before changing the primary compiler.
Vue, Astro, Svelte, MDX, or specialized Angular tooling	Check framework-specific support before switching the full toolchain.
Production-critical project with limited testing capacity	Wait until you can verify compatibility in a representative environment.

If your dependencies support TypeScript 7.0 and compilation is slowing down development or CI, start with a pilot migration and compare your results against the current compiler.

If your project depends on the compiler API or specialized framework tooling, verify the supported migration path first. You may need to retain TypeScript 6.0 for some tools while evaluating TypeScript 7.0 for command-line compilation.

Upgrade when your own measurements demonstrate a worthwhile benefit and your essential development processes remain compatible.

Frequently Asked Questions

Is TypeScript 7.0 faster than TypeScript 6.0?

Microsoft’s published full-build benchmarks show speedups ranging from 7.7× to 11.9× across five selected projects. Your results will depend on your codebase, hardware, build configuration, and caching.

Do I need to change my Node.js setup when upgrading to TypeScript 7.0?

Not necessarily. TypeScript 7.0 uses a native Go-based compiler, but Node.js may still be required for npm, bundlers, test runners, and other JavaScript tools. Review your complete toolchain before changing your environment.

Can I use TypeScript 6.0 and TypeScript 7.0 together?

Yes. Microsoft’s @typescript/typescript6 compatibility package allows tools that need the TypeScript 6.0 API to run alongside TypeScript 7.0. However, package resolution and tool compatibility must be tested.

Will my existing tsconfig.json work unchanged?

Not necessarily. TypeScript 7.0 adopts TypeScript 6.0 defaults and rejects certain deprecated options. Review the migration notes and test your configuration before upgrading.

Should I upgrade immediately?

Start with a pilot if your current build times are a problem and your dependencies appear compatible. If your project depends on specialized framework tooling or the compiler API, verify the supported migration path first.

Conclusion

TypeScript 7.0 offers substantial performance potential for projects where compilation and type-checking slow down development. However, the benefits depend on your codebase, configuration, and development tools.

Before switching, benchmark your current development setup, verify compiler API and framework compatibility, and test the upgrade in a separate branch. If the results show meaningful improvements without disrupting your essential tooling, proceed with a controlled rollout.

Measure your project’s performance and verify compatibility before making TypeScript 7.0 your default compiler.

Building Reliable AI Systems? Explore Our New Context Engineering Handbook

Rajeshwari Pandinagarajan — Fri, 14 Aug 2026 06:39:10 +0000

TL;DR: Why do AI applications fail even with well-crafted prompts? Often, the real problem is a lack of context. The Context Engineering Handbook explores practical techniques for grounding AI with relevant information, helping developers build more accurate, reliable, and production-ready apps.

As AI applications move from prototypes to production, many teams discover that better prompts alone don’t guarantee better results. Instead, the missing piece is often context.

An AI assistant can follow instructions perfectly and still fail if it lacks relevant, up-to-date information. That is why context engineering, the practice of providing models with the right information at the right time, has become a critical part of building reliable AI apps.

We’re excited to introduce the Context Engineering Handbook, a practical guide that explores how developers can build AI applications that are more accurate, grounded, cost-efficient, and reliable.

Why better context often matters more than better prompts

Prompting remains important, but production AI systems also depend on the quality, relevance, and structure of the information available to the model.

For example, consider a customer support assistant answering questions about a company’s refund policy. Even the best prompt cannot compensate for outdated or missing policy information. The model first needs access to the latest documentation before it can provide a reliable answer.

This is where context engineering makes a difference by retrieving, organizing, and delivering the right information at the right time.

Instead of focusing only on instructions, it focuses on the information available to the model when it generates a response. That information may include:

Relevant documents and knowledge sources,
Examples that guide response quality,
Business rules and operational constraints,
User-specific information,
Tool outputs and system state,
Historical conversation context,
Conversation summarization,
Relevance filtering,
Context compression, and
Token budget management.

The goal is simple: provide the information that helps the model complete the task successfully while filtering out unnecessary noise.

What is context engineering?

At its core, context engineering is the practice of designing, assembling, managing, retrieving, and delivering the information an AI model needs to complete a task reliably.

Prompt engineering focuses on how you instruct the model. Context engineering focuses on what information is available to the model when it generates a response.

In practice, this means deciding:

Which information should be included,
Which information should be excluded,
How information should be structured,
When information should be retrieved, and
How context should evolve during execution.

As AI systems become more sophisticated, these decisions can have as much impact on output quality as prompt wording.

Here’s the context engineering pipeline:

User request

↓

Retrieve relevant information

↓

Filter irrelevant content

↓

Rank/prioritize context

↓

Add memory + tools + constraints

↓

Assemble model context

↓

Generate response

↓

Validate output

Prompt engineering vs. Context engineering vs. RAG

For a better understanding, refer to the following comparison table.

Concepts	Primary focus
Prompt engineering	Instructions and task wording.
Context engineering	Selecting and managing information available to the model.
RAG	Retrieving external information and injecting relevant results into model context.

Why good context saves hours of debugging

Many production AI issues can be traced back to poor context management.

When context is weak, teams commonly encounter:

Hallucinated answers,
Inconsistent responses,
Higher token costs,
Loss of conversational,
Difficulty tracing outputs back to source information, and
Increased risk when interacting with external systems.

Grounding responses in trusted data makes AI applications easier to verify, debug, and maintain. As a result, developers can trace answers back to the information that influenced them instead of relying on model assumptions.

A real-world example: AI coding assistants

The impact becomes even clearer when you look at how AI is being used in modern software development.

Imagine an AI coding assistant working inside a large enterprise codebase. Without context, it might generate code that compiles successfully but ignores internal APIs, security requirements, or established architecture patterns.

Now give that assistant access to relevant source files, product requirements, coding standards, architecture documentation, and API contracts. With that context, the generated code becomes far more useful because it reflects how the system is actually built.

User request

↓

Relevant source files

+

Architecture rules

+

API contracts

+

Coding standards

+

Repository instructions

↓

Context selection

↓

AI model

↓

Generated code

The prompt hasn’t changed, but the quality of information available to the model has. That’s the value of context engineering in real-world development environments.

The difference between a great demo and a production system

Many AI projects start with an impressive demo. A few carefully selected examples work perfectly, and the results look promising.

Production, however, is different.

Documentation changes, data grows, business rules evolve, and users ask questions nobody anticipated. As a result, context engineering helps bridge that gap by providing techniques for:

Retrieving relevant information dynamically,
Grounding responses in trusted sources,
Reducing unnecessary token usage, and
Maintaining consistency as applications grow.

Rather than being tied to a specific framework or vendor, these principles apply across modern AI systems.

What you’ll learn about building production AI systems

The Context Engineering Handbook focuses on practical techniques that help teams build more dependable AI applications.

You’ll learn:

How context affects model accuracy and reliability,
Practical approaches such as grounding, RAG, memory, and tool integration, along with techniques for controlling model outputs,
Cost-efficient context strategies, and context optimization techniques,
Common failure patterns and debugging techniques, and
Real-world implementation scenarios from prototype to production.

The focus is on practical concepts and implementation patterns that developers can apply immediately.

Who should read the Context Engineering Handbook?

This guide is designed for:

Developers building AI-powered applications,
Architects designing scalable AI systems,
Product teams integrating AI capabilities, and
Analysts and technical teams managing enterprise knowledge and AI apps.

Whether you’re building a coding assistant, an internal knowledge bot, a document-processing solution, or an enterprise AI application, understanding context engineering can significantly improve output quality.

Turning AI prototypes into reliable systems

Many AI resources focus heavily on prompting techniques. While prompting remains valuable, it is only one piece of the puzzle.

In production, the challenges often involve data freshness, context assembly, retrieval strategies, grounding, traceability, context limits, and long-term reliability.

This Context Engineering Handbook takes a broader view by showing how context is collected, filtered, structured, retrieved, and maintained throughout an application’s lifecycle. You’ll find practical guidance, implementation patterns, common mistakes, and real-world scenarios that reflect how production AI systems are built in practice.

If you’re applying these concepts within enterprise development environments, Syncfusion^®Code Studio provides tools that help developers bring context-aware AI capabilities into everyday software development.

Explore the Context Engineering Handbook to learn practical techniques for building reliable AI systems and try Syncfusion Code Studio to accelerate context-aware development.

For questions or feedback, contact us through our support portal, support forums, or feedback portal. We’re always happy to help.

Build vs. Buy a PDF Viewer: The Real Cost of In-House Development

Rajeshwari Pandinagarajan — Mon, 03 Aug 2026 10:19:23 +0000

TL;DR: Building a PDF viewer involves far more than rendering documents. Hidden costs emerge through compatibility testing, performance optimization, cross-platform support, security, accessibility, feature expansion, and ongoing maintenance. Learn why evaluating the total cost of ownership (TCO) is critical when deciding between building a PDF viewer in-house or adopting a commercial SDK.

Introduction

Understanding PDF viewer development cost requires looking beyond rendering and considering the long-term ownership of compatibility, performance, security, testing, and maintenance.

A prototype that opens PDFs, supports scrolling, and provides zoom controls can often be completed quickly. The real engineering effort begins after deployment, when customers expect accurate rendering across thousands of document variations, smooth performance on large files, annotation workflows, accessibility, security, browser compatibility, and long-term maintenance.

Before choosing to build a PDF viewer in-house, evaluate its total cost of ownership (TCO) rather than only the initial development effort. For many organizations, maintaining PDF infrastructure becomes a larger investment than building the first version.

The prototype that looked finished

The first version often feels complete.

A developer loads a PDF, renders pages, adds zoom controls, enables scrolling, and implements page navigation. During testing, everything works as expected.

Then, real users start uploading documents.

A large engineering drawing.
A scanned contract.
A government form with embedded fonts.
A multilingual document.

Suddenly, new issues appear:

Why does this PDF render differently across browsers?
Why does performance drop with large files?
Why does text search fail on scanned documents?
Why are annotations misaligned after zooming?

These problems rarely surface during prototype testing because prototypes typically use a limited set of predictable documents.

Production environments are different. Users bring PDFs created by different tools, workflows, and systems, each with unique formatting and compatibility challenges.

That’s where the hidden cost of building a PDF viewer begins.

Building a PDF viewer isn’t one decision

One of the biggest misconceptions is that teams have only two options: build a PDF viewer themselves or buy a commercial SDK.

In reality, the decision is more nuanced. Some teams rely on a browser’s native PDF viewer, which is quick to implement but offers limited customization and can behave differently across browsers.

Others use an open-source rendering library, which reduces the effort required to display PDF pages but still leaves the team responsible for building and maintaining many surrounding features.

At the other end of the spectrum is a fully custom PDF viewer, which provides maximum flexibility but also places the entire burden of development, compatibility, testing, and maintenance on the engineering team. Commercial PDF Viewer SDKs shift much of that foundational work to the vendor, allowing teams to focus on business-specific workflows and integrations.

Many organizations assume that adopting an open-source rendering library removes the complexity of PDF viewing. In practice, it simply changes what the team owns.

While the rendering engine may display PDF pages, the application still needs features such as navigation, search, annotations, forms, authentication, accessibility support, browser compatibility handling, performance optimization, testing, and long-term maintenance.

The licensing cost may disappear, but the engineering cost remains.

The PDF viewer capability ladder

Another reason projects exceed their original estimates is that stakeholders rarely stop at basic viewing.

What begins as a simple document viewer gradually evolves into a document platform.

Maturity level	Typical capabilities
Basic viewer	Open, render, scroll, zoom, navigate.
Usable viewer	Search, thumbnails, bookmarks, hyperlinks, printing.
Collaborative viewer	Highlights, comments, annotations, drawing tools.
Interactive experiences	Forms, signatures, page organization, redaction.
Enterprise viewer	Authentication, permissions, audit logs, accessibility.
Document platform	AI-powered search, document extraction, workflow automation, compliance integration.

The engineering effort doesn’t usually increase because the original estimate was inaccurate. It increases because user expectations naturally move up this capability ladder.

The first estimate often assumes the first row, while production eventually demands the last.

Why PDF viewers become more expensive over time

1. Rendering is only the beginning

Rendering the first page of a PDF often feels like the biggest milestone.

In reality, it’s only the foundation.

A production-ready PDF viewer is expected to provide a smooth and consistent reading experience regardless of document size, content, or device. Users quickly expect capabilities such as:

Page thumbnails,
Fit-to-page and fit-to-width viewing,
Smooth scrolling and panning,
Multiple page layouts,
High-quality rendering at different zoom levels,
Rotation and orientation handling, and
Fast navigation through large documents.

Each feature introduces additional rendering logic, state management, and user interaction patterns.

The challenge is no longer simply displaying pages—it’s delivering a viewing experience that feels reliable and responsive under a wide variety of conditions.

Rendering is not a one-time implementation. Teams often need to continuously optimize memory usage, page loading, zoom behavior, and browser-specific rendering differences as document complexity grows.

2. Real-world PDFs are far more diverse than test documents

Most development teams validate a PDF viewer using a relatively small set of sample files.

Production environments are very different.

Customers upload documents generated by dozens of different applications:

Microsoft Office,
Adobe Acrobat,
AutoCAD,
ERP systems,
Medical systems,
Banking software,
Government portals, and
Third-party reporting tools.

Each generator creates PDFs with subtle differences.

Production PDFs can contain embedded fonts, scanned content, OCR layers, forms, annotations, bookmarks, security settings, and many other variations that introduce compatibility challenges.

A document that renders perfectly during internal testing may expose compatibility issues the first time a customer uploads it.

Over time, supporting document compatibility becomes one of the largest ongoing engineering investments, as every new document variation introduces additional testing and validation requirements.

3. Performance becomes a continuous engineering responsibility

Small PDFs rarely reveal performance problems. A ten-page invoice loads almost instantly, while a thousand-page engineering specification tells a different story.

As document sizes grow, rendering, memory consumption, text extraction, search, and scrolling performance become increasingly important to the user experience. Users expect large documents to remain as responsive as small ones, but meeting that expectation requires far more than simply rendering pages.

As usage grows, teams often need to address slow loading times, memory consumption, rendering delays, zoom lag, scrolling performance, and mobile-device limitations.

As browsers evolve and document sizes increase, these optimizations must be revisited repeatedly. Performance is therefore not a completed task; it becomes part of the product’s ongoing lifecycle.

4. Features expand faster than expected

What begins as basic viewing often expands quickly as users request search, annotations, form filling, redaction, and collaboration capabilities.

What started as a document viewer gradually becomes a document workflow platform. Typical requests include search, bookmarks, annotations, form filling, printing, redaction, and collaboration capabilities. While each request may seem manageable individually, together they transform a simple viewer into a document workflow platform.

None of these features exist in isolation.

Annotations affect printing.
Printing affects rendering.
Rendering affects performance.
Forms interact with accessibility.
Security affects every workflow.

Every capability introduces new interactions, testing requirements, and maintenance responsibilities.

Every new capability increases implementation effort, testing requirements, documentation needs, customer support demands, and long-term maintenance responsibilities.

Feature growth is rarely linear. It compounds over time.

5. Supporting multiple platforms multiplies engineering effort

Modern applications rarely target a single environment. Most applications must support multiple browsers, operating systems, desktop environments, tablets, and mobile devices. Ensuring consistent behavior across all these environments significantly increases development and testing effort.

Users expect identical behavior everywhere, but developers know that reality is much more complicated. Different platforms introduce variations in rendering behavior, font handling, printing, touch interactions, file access, memory limits, and accessibility implementations.

As a result, a feature that works perfectly in Chrome may require additional work to behave consistently in Safari or on mobile devices.

6. Enterprise requirements extend beyond features

Many organizations don’t simply need to display PDFs. They build workflows around them.

Legal teams review contracts.
Healthcare professionals access patient records.
Banks process financial statements.
Government agencies manage regulated documents.

Enterprise environments often require more than document viewing. Authentication, authorization, role-based permissions, secure document access, audit trails, and accessibility compliance frequently become mandatory before production deployment. These requirements add both implementation and long-term maintenance complexity.

Accessibility should also be planned from the beginning. Retrofitting keyboard navigation, focus management, accessible controls, and compliance requirements later can require significant redesign effort.

7. Maintenance quickly becomes the highest cost

The first release is only the beginning. Once a PDF Viewer reaches production, engineering ownership continues for years.

Maintenance typically includes:

Browser updates,
Operating system changes,
Rendering improvements,
Security patches,
Compatibility fixes,
Performance tuning,
Feature enhancements,
Customer support, and
Regression testing.

Many teams estimate the effort required to build the first version. Far fewer estimate the effort required to maintain it for the next five years.

The hidden maintenance cycle

Every update triggers another cycle:

As long as the application is supported, this maintenance cycle continues. Over time, rendering, compatibility, testing, and maintenance become interconnected responsibilities that require ongoing engineering investment.

Evaluating the true cost of ownership

Looking beyond development cost

One of the biggest mistakes organizations make when evaluating an in-house PDF Viewer is measuring only the effort required to build the first version.

Initial implementation is only one milestone in a much longer engineering lifecycle.

A production-ready PDF viewer continues to evolve as:

Application requirements change,
Browsers introduce new rendering behavior,
Operating systems evolve,
Accessibility standards mature,
Customers upload new document types,
Security requirements expand, and
Users request additional workflow capabilities.

The true investment isn’t simply development. It’s ownership.

That is why engineering teams should evaluate a PDF viewer using Total Cost of Ownership (TCO) rather than initial implementation cost alone.

A practical total cost of ownership model

Instead of asking,

“How much will it cost to build?”

ask,

“How much will it cost to own?”

A practical way to evaluate ownership is:

PDF viewer TCO = Initial development + feature expansion + compatibility + quality assurance + security & accessibility + infrastructure + maintenance + customer support + opportunity cost

Each category represents work that continues throughout the life of the application.

Breaking down the cost

Cost category	Typical activities
Initial development	Rendering integration, UI, toolbar, navigation, APIs, deployment.
Feature expansion	Search, annotations, forms, signatures, redaction, page management.
Compatibility	Rendering fixes, regression corpus, browser differences, document edge cases.
Quality assurance	Browser testing, platform validation, accessibility testing, visual regression.
Security & compliance	Authentication, authorization, audit logging, permission management, security reviews.
Infrastructure	Document storage, caching, rendering services, monitoring, logging.
Maintenance	Browser updates, framework upgrades, dependency updates, performance tuning.
Support	Customer issue investigation, document analysis, troubleshooting.
Opportunity cost	Engineering time diverted from core product innovation.

Many organizations estimate only the first row. The remaining categories often become the larger investment over time.

The cost that rarely appears in project plans

One of the largest expenses isn’t visible in engineering estimates. It’s opportunity cost.

Every sprint spent maintaining PDF infrastructure is a sprint not spent building features that differentiate the product. For many teams, this opportunity cost becomes one of the largest long-term ownership expenses.

Two organizations may spend the same engineering budget. One invests in customer-facing innovation, while the other maintains document infrastructure. From a product strategy perspective, those investments produce very different outcomes.

A real-world scenario

Imagine a healthcare organization developing an internal PDF viewer for patient records.

During development, the engineering team validates the application using PDFs generated by its own clinical systems, and everything works well. The rollout begins, but then hospitals start uploading documents received from external laboratories, insurance providers, specialist clinics, legacy healthcare systems, and third-party scanning platforms.

Within days, support tickets begin to appear. Some PDFs display missing characters, others render slowly, and a few fail to open entirely.

The engineering team discovers that the production documents differ significantly from those used during testing. The problem extends beyond rendering.

Support must securely collect affected documents.
Security teams review document handling procedures.
QA expands the regression corpus.
Developers investigate rendering behavior.
Product managers delay the rollout while fixes are validated.

The PDF Viewer wasn’t incomplete. It was simply tested against a much smaller set of document variations than production ultimately required. This is a common pattern in enterprise software. Production environments almost always introduce more diversity than internal testing environments.

Recognizing when ownership is becoming expensive

Hidden ownership costs rarely appear at all at once. Instead, they accumulate gradually.

Ownership costs may be increasing when:

PDF-related work appears in most releases.
Compatibility fixes continue to grow.
Performance tuning becomes ongoing work.
Regression testing consumes more time each cycle.
Support tickets frequently involve document issues.
PDF maintenance competes with roadmap priorities.
Specialized PDF expertise becomes concentrated in a few team members.

One or two of these indicators may be manageable. When several appear together, it’s worth re-evaluating whether continued ownership still aligns with the organization’s product strategy.

The hidden cost lifecycle

One customer issue rarely ends with a single bug fix. A typical production issue often follows this path:

A seemingly simple PDF issue can involve multiple teams before reaching production. Repeated across hundreds of customer documents, these workflows can create significant long-term ownership costs.

Build vs. buy isn’t a technical question alone

By this point, one thing should be clear.

Most engineering teams are capable of building a PDF Viewer. The more difficult question is whether they should own one.

Choosing between an in-house implementation and a commercial PDF viewer SDK is rarely about technical ability. It is a strategic decision that affects engineering capacity, product velocity, maintenance effort, and long-term cost of ownership.

There is no universal answer.

For some organizations, building a custom viewer is the right investment.
For others, owning PDF infrastructure diverts engineering resources away from the features that differentiate their product.

The goal is not to avoid building. The goal is to own only the technology that creates competitive value.

A practical build vs. buy decision framework

The following questions can help guide the decision.

Decision factor	More likely to build	More likely to use an SDK
PDF viewing is the product's primary differentiator	✓
Highly specialized rendering requirements	✓
Internal PDF expertise already exists	✓
Full architectural control is essential	✓
Vendor dependency is unacceptable	✓
Fast time to market is important		✓
Rich document workflows are required		✓
Broad browser and platform support is needed		✓
Accessibility compliance is mandatory		✓
Engineering resources should remain focused on business features		✓
PDF functionality supports the application rather than defining it		✓
Long-term maintenance should be minimized		✓

No single answer determines the outcome. Instead, evaluate which column most closely reflects your organization’s priorities.

When building makes sense

Developing a PDF viewer internally may be the right choice when:

PDF technology is central to your business.
The viewer itself is a competitive differentiator.
Requirements are highly specialized.
Long-term ownership aligns with your engineering strategy.
Your organization already possesses deep expertise in PDF rendering and document processing.
You have the resources to support compatibility, accessibility, testing, security, and ongoing maintenance over multiple years.

In these situations, the investment can provide greater flexibility and control.

When an SDK is the better investment

For many organizations, PDF viewing is essential, but it isn’t the feature customers purchase the product for.

An SDK often becomes the more practical choice when:

Time-to-market is critical.
Multiple frameworks or platforms must be supported.
Enterprise features such as annotations, forms, signatures, or redaction are required.
Accessibility and compliance are important.
Engineering teams prefer focusing on business workflows rather than document infrastructure.
Maintaining rendering compatibility is becoming an increasing engineering burden.

The objective is not to avoid engineering work. It is to concentrate engineering effort where it delivers the greatest business value.

Evaluating a PDF viewer SDK

Choosing a PDF viewer SDK should involve the same level of scrutiny as any other long-term technical dependency. Rather than comparing products based solely on feature checklists, evaluate how well they perform in the real-world scenarios your application supports.

1. Document compatibility

A PDF viewer is only as useful as its ability to handle the documents your users work with every day.

During evaluation, test the SDK using actual customer files rather than vendor-provided samples. Include a mix of scanned documents, engineering drawings, large reports, password-protected files, forms, multilingual content, and PDFs generated by different applications.

The goal is to verify that rendering remains accurate and consistent across the document types most relevant to your business.

2. Performance

Performance should be assessed under realistic conditions, not just with small sample documents. Pay attention to how quickly the first page loads, how smoothly large documents scroll, how responsive search operations feel, and how well the viewer performs when users zoom, navigate, or switch pages. It’s also important to evaluate memory consumption and responsiveness on mobile devices, particularly if your application serves a diverse user base.

3. Feature coverage

A useful evaluation should consider not only today’s requirements but also the features your team may need in the future. Capabilities such as searching, bookmarks, annotations, comments, form filling, redaction, printing, and page organization are common requirements in production environments. Selecting an SDK that already supports anticipated workflows can help avoid costly custom development or migrations later.

4. Security

PDF viewers often sit within applications that handle sensitive information, making security a critical evaluation criterion. Review how the SDK integrates with authentication and authorization systems, supports document access controls, and fits into your security architecture. It is also worth examining deployment options, audit capabilities, document retrieval mechanisms, and any requirements related to data residency or regulatory compliance.

5. Accessibility

Accessibility should be treated as a core product requirement rather than a secondary feature. A strong PDF viewer SDK should support keyboard navigation, logical focus management, accessible forms, high-contrast themes, and compatibility with accessibility standards. Evaluating these capabilities early can help reduce the risk of expensive accessibility remediation work later.

6. Long-term ownership

Beyond technical capabilities, consider what it will be like to rely on the vendor over the next several years. Review the frequency of updates, the quality of documentation, the availability of technical support, and how quickly security or compatibility issues are addressed. Understanding the product roadmap can also help determine whether the SDK is likely to evolve alongside your application’s future requirements.

Ultimately, a PDF viewer SDK is more than a UI component. It becomes part of your application’s long-term technical foundation, so the evaluation process should focus not only on features but also on compatibility, performance, supportability, and long-term ownership.

How Syncfusion addresses these ownership challenges

The engineering challenges discussed throughout this article map directly to capabilities available in the Syncfusion® PDF Viewer SDK.

Engineering challenge	Syncfusion capability	Engineering benefit
Diverse PDF compatibility	High-fidelity rendering engine	Consistent rendering across a wide range of PDF documents
Large-document performance	Virtual page rendering, progressive loading	Lower memory usage and smoother navigation
Feature expansion	Built-in search, annotations, forms, signatures, redaction, printing	Reduces the need to build common document workflows from scratch
Cross-platform support	Web, desktop, and mobile support	Consistent behavior across deployment targets
Security	Authentication integration, permission controls, secure viewing options	Easier integration into enterprise applications
Accessibility	Keyboard navigation, accessible UI, tagged PDF support	Helps organizations build more inclusive document experiences
Long-term maintenance	Regular product updates, documentation, and technical support	Reduces ongoing ownership of foundational PDF infrastructure

Using a commercial SDK does not eliminate engineering responsibility.

Development teams still own:

Business logic,
Authentication,
Application-specific workflows,
Integration,
Testing,
Deployment, and
User experience.

What changes is which layer of the stack the organization chooses to own.

Rather than investing engineering effort in rendering engines, compatibility fixes, and document infrastructure, teams can focus on the workflows that differentiate their applications.

Frequently asked questions

Q1. How much does it cost to build a PDF viewer?

There is no fixed cost. It depends on the scope of the project, whether you’re using a browser-native viewer, building an open-source rendering library, developing a fully custom viewer, or integrating a commercial SDK. The true estimate should include long-term maintenance, testing, compatibility, accessibility, and support, not just initial development.

Q2. Is using an open-source PDF library free?

An open-source rendering library may eliminate licensing fees, but it does not eliminate engineering ownership. Teams are still responsible for building user workflows, maintaining compatibility, optimizing performance, testing across browsers, and supporting production issues.

Q3. What is the most difficult part of PDF Viewer development?

Many teams assume rendering is the hardest challenge. In practice, long-term compatibility, performance optimization, accessibility, testing, and supporting diverse real-world documents often require more engineering effort than the initial implementation.

Q4. When should a company build its own PDF viewer?

Building is generally appropriate when PDF technology is a core product differentiator, requirements are highly specialized, and the organization has the engineering capacity to maintain the solution over the long term.

Q5. When is a PDF viewer SDK the better choice?

A commercial SDK is often the better investment when organizations need enterprise features, broad compatibility, cross-platform support, faster delivery, and the ability to keep engineering teams focused on business-specific functionality.

Final thoughts

A PDF viewer prototype can often be built in a matter of days or weeks. A production-ready PDF platform is a long-term engineering commitment. The real investment begins after the first document renders.

It continues through:

Supporting unpredictable PDF documents,
Maintaining rendering quality,
Optimizing performance,
Expanding feature sets,
Ensuring accessibility,
Managing security,
Testing across browsers and devices,
Investigating customer-reported documents, and
Keeping pace with evolving web platforms.

None of these responsibilities automatically mean that organizations should avoid building a PDF viewer.

In many cases, building is absolutely the right architectural decision.

But it should be a deliberate decision based on the total PDF viewer development cost and long-term cost of ownership, not simply the effort required to produce an initial prototype.

The most successful teams focus their engineering effort on capabilities that differentiate their products. Whether you choose to build or buy, understanding the long-term ownership implications is the key to making the right decision.

If your goal is to deliver enterprise-grade PDF viewing without absorbing the long-term cost of building and maintaining document infrastructure, the Syncfusion PDF Viewer SDK provides a production-ready foundation with built-in support for rendering, annotations, forms, signatures, redaction, accessibility, and security workflows across .NET, JavaScript, Blazor, Angular, React, Vue, and other supported platforms.

Instead of dedicating engineering resources to rendering engines, compatibility testing, and ongoing maintenance, teams can focus on building business-specific workflows that create customer value.

A Complete Guide to Creating a Mind Map Using Angular Diagram Component

Rajeshwari Pandinagarajan — Fri, 23 Dec 2022 11:02:33 +0000

A single mind map can better illustrate concepts or ideas than a thousand words. We can easily display various ideas associated with a specific concept.

The Syncfusion Angular Diagram component is a powerful, extensible, and feature-rich library for visualizing, creating, and editing interactive diagrams.

In this blog, we will see how to create a mind map diagram using the Syncfusion Angular Diagram component.

Create a mind map diagram

The Syncfusion Angular Diagram component provides support to visualize mind maps from external data sources. In addition, data in any format can be easily converted, mapped, and consumed in the Diagram by setting a few properties.

We are going to design the following mind map in this article.

Creating a mind map using the Angular Diagram component

In this image, the ellipse, rectangular boxes, and thick, straight lines with text represent nodes, while the curved lines represent connectors. The text inside the ellipse, rectangular box, and straight lines represent annotations.

Follow these steps to create the mind map diagram using our Angular Diagram component:

First, refer to the Getting started with Angular Diagram component documentation to see the dependent scripts and theme files required to integrate the component into your Angular application.
Second, define the tree information as a JSON array.
Create an instance of the Angular Diagram component.
Then, configure the data to the dataSourceSettings property of the created Diagram instance.
Define the common formatting for all nodes and connectors through the getNodeDefaults and getConnectorDefaults methods, respectively.
After configuring the data source, define the layout type as a mindmap to arrange the nodes’ positions automatically.

The following code example includes all these steps. You can also find the same code on this StackBlitz page.

.html

<div> 
    <ejs-diagram #diagram id="diagram" width="100%" height="700px" [getNodeDefaults]=getNodeDefaults [snapSettings]=snapSettings [scrollSettings]="scrollSettings" [selectedItems]="selectedItems" [getCustomTool]='getCustomTool' (selectionChange)="selectionChange($event)" (created)="create($event)" [tool]=tool [layout]='layout' [dataSourceSettings]='data' [getConnectorDefaults]='getConnDefaults'>
    </ejs-diagram>
</div>

.ts

import { Component, ViewEncapsulation, ViewChild } from '@angular/core';
import {
  DiagramComponent,
  Diagram,
  ConnectorModel,
  Connector,
  Node,
  HierarchicalTree,
  DataBinding,
  PointPortModel,
  SnapSettingsModel,
  ScrollSettingsModel,
  PortVisibility,
  MindMap,
  SnapConstraints,
  NodeModel,
  DiagramTools,
  ConnectorConstraints,
  PointPort,
} from '@syncfusion/ej2-angular-diagrams';
import { DataManager } from '@syncfusion/ej2-data';
Diagram.Inject(DataBinding, MindMap, HierarchicalTree);
/**
 * Sample for Mind Map Tree
 */
@Component({
  selector: 'app-root',
  templateUrl: 'app.component.html',
  styleUrls: ['app.component.css'],
  encapsulation: ViewEncapsulation.None,
})
export class AppComponent {
  @ViewChild('diagram') public diagram: DiagramComponent;
  public tool: DiagramTools = DiagramTools.ZoomPan;
  public Data: object[] = [
    { id: 1, Label: 'Creativity', fill: 'red', branch: 'Root' },
    {
      id: 3,
      Label: 'Brainstorming',
      parentId: 1,
      branch: 'Right',
      fill: 'red',
    },
    { id: 4, Label: 'Complementing', parentId: 1, branch: 'Left', fill: 'red' },
    { id: 22, Label: 'Sessions', parentId: 3, branch: 'subRight', fill: 'red' },
    { id: 23, Label: 'Generate', parentId: 3, branch: 'subRight', fill: 'red' },
    { id: 25, Label: 'Local', parentId: 22, branch: 'subRight' },
    { id: 26, Label: 'Remote', parentId: 22, branch: 'subRight' },
    { id: 27, Label: 'Individual', parentId: 22, branch: 'subRight' },
    { id: 28, Label: 'Teams', parentId: 22, branch: 'subRight' },
    { id: 29, Label: 'Ideas', parentId: 23, branch: 'subRight' },
    { id: 30, Label: 'Engagement', parentId: 23, branch: 'subRight' },
    { id: 31, Label: 'Product', parentId: 29, branch: 'subRight' },
    { id: 32, Label: 'Service', parentId: 29, branch: 'subRight' },
    { id: 33, Label: 'Business Direction', parentId: 29, branch: 'subRight' },
    { id: 34, Label: 'Empowering', parentId: 30, branch: 'subRight' },
    { id: 35, Label: 'Ownership', parentId: 30, branch: 'subRight' },
    { id: 50, Label: 'Information', parentId: 4, branch: 'subLeft' },
    { id: 51, Label: 'Expectations', parentId: 4, branch: 'subLeft' },
    { id: 53, Label: 'Competitors', parentId: 50, branch: 'subLeft' },
    { id: 54, Label: 'Products', parentId: 50, branch: 'subLeft' },
    { id: 55, Label: 'Features', parentId: 50, branch: 'subLeft' },
    { id: 56, Label: 'Other Data', parentId: 50, branch: 'subLeft' },
    { id: 59, Label: 'Organization', parentId: 51, branch: 'subLeft' },
    { id: 60, Label: 'Customer', parentId: 51, branch: 'subLeft' },
    { id: 61, Label: 'Staff', parentId: 51, branch: 'subLeft' },
    { id: 62, Label: 'Stakeholders', parentId: 51, branch: 'subLeft' },
  ];
  //Get mind map data.
  public items: DataManager = new DataManager(this.Data);
  public data: Object = {
    id: 'id',
    parentId: 'parentId',
    dataSource: this.items,
    root: '1',
  };
  //Define layout.
  public layout: Object = {
    type: 'MindMap',
    horizontalSpacing: 40,
    getBranch: (node: NodeModel, nodes: NodeModel[]) => {
      return ((node as Node).data as TreeInfo).branch;
    },
  };
  public snapSettings: SnapSettingsModel = {
    constraints: SnapConstraints.None,
  };
  public scrollSettings: ScrollSettingsModel = {
    scrollLimit: 'Infinity',
  };
  public create(args: Object): void {
    this.diagram.fitToPage();
  }
  //Define node default settings.
  public getNodeDefaults: Function = this.nodeDefaults.bind(this);
  //Define connector default settings
  public getConnDefaults: Function = this.getConnectorDefaults.bind(this);
  private nodeDefaults(obj: NodeModel): NodeModel {
    let treeInfo: TreeInfo = obj.data as TreeInfo;
    obj.shape = { type: 'Basic', shape: 'Ellipse' };
    obj.borderColor = 'black';
    obj.style = {
      fill:
        treeInfo.branch === 'Right' || treeInfo.branch === 'subRight'
          ? '#8E44AD'
          : treeInfo.branch === 'Left' || treeInfo.branch === 'subLeft'
          ? '#3498DB'
          : '#E74C3C',
      strokeColor: 'none',
      strokeWidth: 2,
    };
    obj.annotations = [
      {
        content: (obj.data as TreeInfo).Label,
        margin: { left: 10, right: 10, top: 10, bottom: 10 },
        style: { color: 'white' },
      },
    ];
    let port: PointPortModel[] = this.getPort();
    for (let i: number = 0; i < port.length; i++) {
      obj.ports.push(new PointPort(obj, 'ports', port[i], true));
    }
    return obj;
  }
  //sets connector default value.
  private getConnectorDefaults(
    connector: ConnectorModel,
    diagram: Diagram
  ): ConnectorModel {
    connector.type = 'Bezier';
    connector.targetDecorator = { shape: 'None' };
    let sourceNode: Node = diagram.getObject(connector.sourceID) as Node;
    let targetNode: Node = diagram.getObject(connector.targetID) as Node;
    let treeInfo: TreeInfo = targetNode.data as TreeInfo;
    connector.constraints &= ~ConnectorConstraints.Select;
    if (treeInfo.branch === 'Right' || treeInfo.branch === 'subRight') {
      connector.sourcePortID = sourceNode.ports[0].id;
      connector.targetPortID = targetNode.ports[1].id;
    } else if (treeInfo.branch === 'Left' || treeInfo.branch === 'subLeft') {
      connector.sourcePortID = sourceNode.ports[1].id;
      connector.targetPortID = targetNode.ports[0].id;
    }
    return connector;
  }
  private getPort(): PointPortModel[] {
    let port: PointPortModel[] = [
      {
        id: 'port1',
        offset: { x: 0, y: 0.5 },
        visibility: PortVisibility.Hidden,
        style: { fill: 'black' },
      },
      {
        id: 'port2',
        offset: { x: 1, y: 0.5 },
        visibility: PortVisibility.Hidden,
        style: { fill: 'black' },
      },
    ];
    return port;
  }
}
export interface TreeInfo {
  branch: string;
  color: string;
  Left: string;
  Right: string;
  Root: string;
  Label: string;
  Level: string;
}

Interactivity using keyboard and mouse

You can interactively build the mind map diagram using the mouse, touch, and keyboard interfaces. Let’s see how to do so with code examples.

Quick commands

Frequently used commands can be shown as buttons near a selector. You can define the actions as commands for buttons. By doing so, you can perform that action by just clicking the button.

Refer to the following code example and the same on StackBlitz. Here, we have rendered buttons for deleting and left- and right-handling actions.

public handle: UserHandleModel[] = [
    {
      name: 'leftHandle',
      visible: true,
      backgroundColor: 'black',
      offset: 1,
      side: 'Left',
      pathColor: 'white',
      pathData:
        'M11.924,6.202 L4.633,6.202 L4.633,9.266 L0,4.633 L4.632,0 L4.632,3.551 L11.923,3.551 L11.923,6.202Z',
      margin: { top: 0, bottom: 0, left: 0, right: 10 },
      horizontalAlignment: 'Left',
      verticalAlignment: 'Top',
    },
    {
      name: 'delete',
      side: 'Top',
      horizontalAlignment: 'Center',
      verticalAlignment: 'Center',
      pathData:
        'M 7.04 22.13 L 92.95 22.13 L 92.95 88.8 C 92.95 91.92 91.55 94.58 88.76' +
        '96.74 C 85.97 98.91 82.55 100 78.52 100 L 21.48 100 C 17.45 100 14.03 98.91 11.24 96.74 C 8.45 94.58 7.04' +
        '91.92 7.04 88.8 z M 32.22 0 L 67.78 0 L 75.17 5.47 L 100 5.47 L 100 16.67 L 0 16.67 L 0 5.47 L 24.83 5.47 z',
      margin: { top: 0, bottom: 10, left: 0, right: 0 },
      offset: 0.5,
      pathColor: 'white',
    },
    {
      name: 'rightHandle',
      offset: 1,
      horizontalAlignment: 'Right',
      verticalAlignment: 'Top',
      pathColor: 'white',
      pathData:
        'M0,3.063 L7.292,3.063 L7.292,0 L11.924,4.633 L7.292,9.266 L7.292,5.714 L0.001,5.714 L0.001,3.063Z',
      side: 'Right',
      backgroundColor: 'black',
      margin: { top: 0, bottom: 0, left: 10, right: 0 },
    },
  ];
  public selectedItems: SelectorModel = {
    constraints: SelectorConstraints.UserHandle,
    userHandles: this.handle,
  };

Creating mind map using quick commands in Angular Diagram component

Shortcut keys

Using the shortcut keys, you can quickly create mind maps. Based on the specific key gestures, you can specify the actions to be executed.

For example, Tab can be used to add a new topic to the right, Shift+Tab to the left, and Delete to delete the topic and its subtopics.

Refer to the following code example and the same on StackBlitz.

 this.diagram.commandManager = {
      commands: [
        {
          gesture: { key: Keys.Tab },
          canExecute: this.canExecute.bind(this),
          execute: this.addLeftChild.bind(this),
          name: 'leftChild',
        },
        {
          gesture: { key: Keys.Tab, keyModifiers: KeyModifiers.Shift },
          canExecute: this.canExecute.bind(this),
          execute: this.addRightChild.bind(this),
          name: 'rightChild',
        },
        {
          gesture: { key: Keys.Delete },
          canExecute: this.canExecute.bind(this),
          execute: this.removeChild.bind(this),
          name: 'deleteChid',
        },
      ],
    };
private addLeftChild() {
    let selectedObject: any = this.diagram.selectedItems.nodes;
    if (selectedObject[0]) {
      if (selectedObject[0] instanceof Node) {
        let node: NodeModel = addNode();
        let empInfo: EmployeeInfo = selectedObject[0].data as EmployeeInfo;
        if (empInfo.branch === 'Root') {
          (node.data as EmployeeInfo).branch = 'Right';
        } else if (
          empInfo.branch === 'Right' ||
          empInfo.branch === 'subRight'
        ) {
          (node.data as EmployeeInfo).branch = 'subRight';
        } else if (empInfo.branch === 'Left' || empInfo.branch === 'subLeft') {
          (node.data as EmployeeInfo).branch = 'subLeft';
        }
        let connector: ConnectorModel = addConnector(selectedObject[0], node);
        this.diagram.clearSelection();
        let nd: Node = this.diagram.add(node) as Node;
        this.diagram.add(connector);
        this.diagram.doLayout();
        this.diagram.startTextEdit(nd);
      }
    }
  }
  private addRightChild() {
    let selectedObject: any = this.diagram.selectedItems.nodes;
    if (selectedObject[0]) {
      if (selectedObject[0] instanceof Node) {
        let node: NodeModel = addNode();
        let empInfo: EmployeeInfo = selectedObject[0].data as EmployeeInfo;
        if (empInfo.branch === 'Root') {
          (node.data as EmployeeInfo).branch = 'Left';
        } else if (empInfo.branch === 'Left' || empInfo.branch === 'subLeft') {
          (node.data as EmployeeInfo).branch = 'subLeft';
        } else if (
          empInfo.branch === 'Right' ||
          empInfo.branch === 'subRight'
        ) {
          (node.data as EmployeeInfo).branch = 'subRight';
        }
        let connector: ConnectorModel = addConnector(selectedObject[0], node);
        this.diagram.clearSelection();
        let nd: Node = this.diagram.add(node) as Node;
        this.diagram.add(connector);
        this.diagram.doLayout();
        this.diagram.startTextEdit(nd);
      }
    }
  }
  private removeChild() {
    let selectedObject: any = this.diagram.selectedItems.nodes;
    if (selectedObject[0]) {
      if (selectedObject[0] instanceof Node) {
        let node: Node = selectedObject[0] as Node;
        this.removeSubChild(node);
      }
      this.diagram.doLayout();
    }
  }
  //Remove the subchild Elements
  private removeSubChild(node: Node): void {
    for (let i: number = node.outEdges.length - 1; i >= 0; i--) {
      let connector: Connector = this.diagram.getObject(
        node.outEdges[i]
      ) as Connector;
      let childNode: Node = this.diagram.getObject(connector.targetID) as Node;
      if (childNode.outEdges.length > 0) {
        this.removeSubChild(childNode);
      } else {
        this.diagram.remove(childNode);
      }
    }
    this.diagram.remove(node);
  }

Creating a Mind Map using Keyboard Shortcuts in Angular Diagram Component

Expand and collapse children nodes

Use the expandIcon and collapseIcon properties of nodes to implement the expand and collapse features in the mind map’s children nodes.

Refer to the following example and the same on StackBlitz.

private getNodeDefaults(obj: NodeModel): NodeModel {
    ........ 
        obj.expandIcon = {
          shape: 'Minus',
        };
        obj.collapseIcon = {
          shape: 'Plus',
        };
    ........ 
    return obj;
  }

Expanding and collapsing nodes in a mind map using Angular Diagram component

Drag and drop

You can easily change the mind map layout by dragging a topic or subtopic and dropping it on the required location.

Add the following code to the Diagram control’s drop method to enable editing in the mind map’s tree structure. Also, the same code is available on StackBlitz.

public drop(args): void {
    if (args.target && args.target instanceof Node) {
      let connector: ConnectorModel = this.diagram.getObject(
        args.element.inEdges[0]
      );
      connector.sourceID = args.target.id;
      this.diagram.dataBind();
      this.diagram.doLayout();
      //Update connector connection direction.
      let srcNode: NodeModel = args.element;
      let targetNode: NodeModel = args.target;
      let srctreeInfo: TreeInfo = srcNode.data as TreeInfo;
      let targettreeInfo: TreeInfo = targetNode.data as TreeInfo;
      if (
        (srctreeInfo.branch === 'Right' || srctreeInfo.branch === 'subRight') &&
        (targettreeInfo.branch === 'Left' ||
          targettreeInfo.branch === 'subLeft')
      ) {
        connector.sourcePortID = targetNode.ports[1].id;
        connector.targetPortID = srcNode.ports[0].id;
        this.updateRightTopicOutEdges(srcNode);
      } else if (
        (srctreeInfo.branch === 'Left' || srctreeInfo.branch === 'subLeft') &&
        (targettreeInfo.branch === 'Right' ||
          targettreeInfo.branch === 'subRight')
      ) {
        connector.sourcePortID = targetNode.ports[0].id;
        connector.targetPortID = srcNode.ports[1].id;
        this.updateLeftTopicOutEdges(srcNode);
      }
      // update your local data source when modifying mind map topics.
      this.updateDataSource(args.element, args.target);
    }
  }
  private updateRightTopicOutEdges(node: NodeModel) {
    for (var i = 0; i < (node as Node).outEdges.length; i++) {
      let outconnector: ConnectorModel = this.diagram.getObject(
        (node as Node).outEdges[i]
      );
      outconnector.sourcePortID = 'port2';
      outconnector.targetPortID = 'port1';
      let targetNode: NodeModel = this.diagram.getObject(outconnector.targetID);
      if ((targetNode as Node).outEdges) {
        this.updateRightTopicOutEdges(targetNode);
      }
    }
  }
  private updateLeftTopicOutEdges(node: NodeModel) {
    for (var i = 0; i < (node as Node).outEdges.length; i++) {
      let outconnector: ConnectorModel = this.diagram.getObject(
        (node as Node).outEdges[i]
      );
      outconnector.sourcePortID = 'port1';
      outconnector.targetPortID = 'port2';
      let targetNode: NodeModel = this.diagram.getObject(outconnector.targetID);
      if ((targetNode as Node).outEdges) {
        this.updateLeftTopicOutEdges(targetNode);
      }
    }
  }
  private updateDataSource(source, target): void {
    let updateData = this.Data.find(function (element) {
      return element.id === source.data.id;
    });
    if (updateData) {
      updateData.parentId = target.data.id;
    }
  }

Dragging and dropping nodes in a mind map using Angular Diagram component

Mind map shape customization

You can easily customize the appearance of each level of nodes by adding backgrounds, border styles, text styles, and images and visualize them with a custom UI design.

The getNodeDefaults method lets you specify a custom shape and style for each node based on its level value.

Refer to the following code example and the same on StackBlitz.

private getNodeDefaults(obj: NodeModel): NodeModel {
    obj.constraints = NodeConstraints.Default & ~NodeConstraints.Drag;
    let empInfo: TreeInfo = obj.data as TreeInfo;
    if (
      empInfo.branch === 'Root' ||
      empInfo.branch === 'Left' ||
      empInfo.branch === 'Right'
    ) {
      obj.shape = {
        type: 'Basic',
        shape: empInfo.branch === 'Root' ? 'Ellipse' : 'Rectangle',
      };
      obj.borderColor = 'black';
      obj.style = {
        fill: empInfo.branch === 'Root' ? '#E74C3C' : '#F39C12',
        strokeColor: 'none',
        strokeWidth: 2,
      };
      obj.annotations = [
        {
          content: empInfo.Label,
          margin: { left: 10, right: 10, top: 10, bottom: 10 },
          style: { color: 'white' },
        },
      ];
      if (empInfo.branch === 'Left' || empInfo.branch === 'Right') {
        obj.height = 40;
        obj.width = 100;
      }
    } else {
      let color: string =
        empInfo.branch === 'subRight'
          ? empInfo.Level === '2'
            ? 'Green'
            : '#8E44AD'
          : empInfo.Level === '2'
          ? 'Green'
          : '#3498DB';
      obj.shape = {
        type: 'Basic',
        shape: empInfo.Level === '2' ? 'Ellipse' : 'Rectangle',
      };
      obj.style = { fill: color, strokeWidth: 0 };
      obj.minWidth = 100;
      obj.height = empInfo.Level === '2' ? 30 : 4;
      obj.annotations = [
        {
          content: empInfo.Label,
          offset: empInfo.Level === '2' ? { x: 0.5, y: 0.5 } : { x: 0.5, y: 0 },
          verticalAlignment: empInfo.Level === '2' ? 'Center' : 'Bottom',
          style: { color: empInfo.Level === '2' ? 'white' : 'black' },
        },
      ];
      (obj.shape as TextModel).margin = {
        left: 0,
        right: 0,
        top: 0,
        bottom: 0,
      };
    }
    let port: PointPortModel[] = this.getPort();
    for (let i: number = 0; i < port.length; i++) {
      (obj as any).ports.push(new PointPort(obj, 'ports', port[i], true));
    }
    return obj;
  }
  //sets connector default value
  private getConnectorDefaults(
    connector: ConnectorModel | any,
    diagram: Diagram
  ): ConnectorModel {
    let sourceNode: Node = diagram.getObject(connector.sourceID) as Node;
    let targetNode: Node = diagram.getObject(connector.targetID) as Node;
    let empInfo: TreeInfo = targetNode.data as TreeInfo;
    connector.type = 'Bezier';
    connector.targetDecorator = { shape: 'None' };
    connector.constraints &= ~ConnectorConstraints.Select;
    if (empInfo.branch === 'Right' || empInfo.branch === 'subRight') {
      connector.sourcePortID = sourceNode.ports[0].id;
      connector.targetPortID = targetNode.ports[1].id;
      connector.style = { strokeWidth: 5, strokeColor: '#8E44AD' };
    } else if (empInfo.branch === 'Left' || empInfo.branch === 'subLeft') {
      connector.sourcePortID = sourceNode.ports[1].id;
      connector.targetPortID = targetNode.ports[0].id;
      connector.style = { strokeWidth: 5, strokeColor: '#3498DB' };
    }
    return connector;
  }
  private getPort(): PointPortModel[] {
    let port: PointPortModel[] = [
      {
        id: 'port1',
        offset: { x: 0, y: 0.5 },
        visibility: PortVisibility.Hidden,
        style: { fill: 'black' },
      },
      {
        id: 'port2',
        offset: { x: 1, y: 0.5 },
        visibility: PortVisibility.Hidden,
        style: { fill: 'black' },
      },
    ];
    return port;
  }

Customizing the shapes in a mind map using the Angular Diagram component

Spacing

Adjust the spacing between each level of the mind map diagram horizontally and vertically. You can also define a margin around the mind map diagram, like in the following code example.

public layout: Object = {
    type: 'MindMap',
    horizontalSpacing: 80,
    verticalSpacing: 80,
    getBranch: (node: NodeModel, nodes: NodeModel[]) => {
      return ((node as Node).data as TreeInfo).branch;
    },
  };

Customizing the spacing between nodes in a mind map using the Angular Diagram component

Zooming and panning

Viewing a large mind map on a small screen can be challenging. In that case, zooming and panning help us provide a more detailed view of the mind map.

You can zoom in and out of the diagram using the Ctrl + mouse wheel shortcut key.

Refer to the following code examples and the same on StackBlitz to enable zooming and panning support in the mind map diagram.

.html

<div class="col-lg-8 control-section" style="width: 100%;">
  <div class="content-wrapper">
    <ejs-diagram
      #diagram
      id="diagram"
      width="100%"
      height="700px"
      [getNodeDefaults]="getShapeDefaults"
      [snapSettings]="snapSettings"
      [scrollSettings]="scrollSettings"
      [tool]="tool"
      [layout]="layout"
      [dataSourceSettings]="data"
      [getConnectorDefaults]="getConnDefaults"
    >
    </ejs-diagram>
  </div>
</div>

.ts

//Enable pan tool.
  public tool: DiagramTools = DiagramTools.ZoomPan;

Zooming and panning in a mind map using Angular Diagram component

Exporting

You can easily export the mind map diagram to different image formats such as PNG, JPEG, BMP, and SVG.

Refer to the following code example and the same on StackBlitz to explore this feature.

let exportOptions: IExportOptions = {};
    exportOptions.format = args.item.text as FileFormats;
    exportOptions.mode = 'Download';
    exportOptions.region = 'Content';
    exportOptions.multiplePage = false;
    exportOptions.fileName = 'Mindmap';
    this.diagram.exportDiagram(exportOptions);

Conclusion

Thanks for reading! In this blog post, we have seen how to create and customize a mind map using the Syncfusion Angular Diagram component. With the same component, you can also create flowcharts, organizational charts, floor plans, UML diagrams, and BPMN charts. Try out the steps in this blog and provide your feedback in the comments section!

If you would like to try out the Diagram, You can download our free trial. You can also look at the Diagram source on GitHub and check our live demo and documentation for detailed explanations.

Related blogs

Introducing the New Angular Image Editor Component

Rajeshwari Pandinagarajan — Fri, 11 Nov 2022 12:19:27 +0000

We are happy to introduce the new Angular Image Editor component with our latest release, 2022 Volume 3!

Let’s explore its features and UI design!

Image Editor overview

The Angular Image Editor is a graphical user interface for editing images. It provides built-in support to rotate, flip, zoom, and crop images. Users can insert annotations including text, freehand drawings, and shapes such as rectangles, ellipses, and lines. Also, the control supports keyboard interactions, events, and an optimized UI for touch gestures.

The following GIF image shows some of its features in action.

Angular Image Editor Component

Use cases

The Angular Image Editor is a great fit for the following applications:

Profile pictures : Crop any image and use it as your profile picture through the component’s user-friendly APIs. You can customize the Image Editor’s capabilities for this use by changing its toolbar or using external buttons.
Photo editor : Use all the common image editing features built into the component’s toolbar. You can easily integrate the Image Editor into web or mobile applications to provide image editing capabilities.

Key features

The following are the key features available in the Angular Image Editor component:

Load and save an image.
Select and crop an image.
Transform an image.
Annotate an image.
Zoom and pan an image.
Customize the toolbar.
Responsive, touch-friendly UI.

Let’s see how these features work with code examples.

Load and save an image

The Image Editor component can open base64, image data, or hosted and online URL images using the open ** method. You can also open an image by clicking the **Open button in the toolbar. The supported file types are PNG, JPEG, SVG, and base64.

Users can also edit images and save them as ImageData using the getImageData method. To save images in PNG, JPEG, and SVG formats, users can use the export method, which accepts file type and file name as parameters.

In the following code example, the open method is used to open a hosted image.

<div id="wrapperDiv" style="width:550px; height:350px;">
  <ejs-imageeditor (created)="created()" #ImageEditor [toolbar]='toolbarItems'></ejs-imageeditor>
</div>

export class AppComponent {
 @ViewChild('ImageEditor')
 public ImageEditorInstance!: ImageEditorComponent;
 public toolbarItems: string[] = [];
 public created = (): void => {
  this.ImageEditorInstance.open("http://localhost:6969/image/bridge.png");
 }
}

The output of this code example is shown in the following image.

Viewing an Image Using Angular Image Editor

Note: To view hosted images, you need to enable the Directory Browsing option in IIS , which creates a web.config file inside the hosted folder. Add the following code in the web.config file to resolve the CORS issue.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
 <system.webServer>
 <directoryBrowse enabled="true" />
  <httpProtocol>
   <customHeaders>
    <clear />
    <add name="Access-Control-Allow-Origin" value="*" />
   </customHeaders>
  </httpProtocol>
 </system.webServer>
</configuration>

Selection and cropping

The Image Editor component supports multiple selection options including square, circle, and custom shapes. It can also handle various aspect ratios. You can crop an image by dragging and resizing the selection region. You can perform selection by either using the toolbar or the select method.

In the select method, we have to specify the selection type (custom, square, or circle) and aspect ratios (3:2, 4:3, 5:4, 7:5, or 16:9).

In the toolbar , we can perform selection by just clicking the Crop dropdown button and picking a selection shape (custom, square, or circle) and aspect ratio.

Cropping

The Angular Image Editor can crop any image based on a user-defined selection. The cropping can be made by either using the toolbar or the crop method.

In the toolbar , we can perform cropping by clicking the *OK * button that is enabled after the user selects a part of the image.

In the following code example, we have used the select and crop methods to perform circular selection and crop the image.

<div>
 <div style="padding-bottom: 10px;">
  <button class="e-btn" (click)="select()">Select</button>
  <button class="e-btn" (click)="crop()">Crop</button>
 </div>
 <div id="wrapperDiv" style="width:550px; height:350px;">
  <ejs-imageeditor (created)="created()" #ImageEditor [toolbar]='toolbarItems'></ejs-imageeditor>
 </div>
</div>
export class AppComponent {
 @ViewChild('ImageEditor')
 public ImageEditorInstance!: ImageEditorComponent;
 public toolbarItems: string[] = [];
 public created = (): void => {
  this.ImageEditorInstance.open("http://localhost:6969/image/bridge.png");
 }
 public select = (): void => {
  this.ImageEditorInstance.select('circle');
 }
 public crop = (): void => {
  this.ImageEditorInstance.crop();
 }
}

Cropping an Image Using Angular Image Editor

Transform an image

The Angular Image Editor component has rotate and flip transformation support. The rotation transformation allows users to rotate an image clockwise or counterclockwise 90, 180, 270, or 360 degrees. The flip transformation supports horizontal and vertical orientations. We can perform both transformations by either using the toolbar or the rotate and flip methods.

In the toolbar , we can perform rotate and flip actions by clicking the Transform dropdown button and selecting one of the Rotate Left , Rotate Right , Horizontal Flip , or Vertical Flip options.

In the following code example, the rotate and flip methods are used to perform rotation and flip actions.

<div>
 <div style="padding-bottom: 10px;">
  <button class="e-btn" (click)="rotate()">Rotate</button>
  <button class="e-btn" (click)="flip()">Flip</button>
 </div>
 <div id="wrapperDiv" style="width:550px; height:350px;">
  <ejs-imageeditor (created)="created()" #ImageEditor [toolbar]='toolbarItems'></ejs-imageeditor>
 </div>
</div>


export class AppComponent {
 @ViewChild('ImageEditor')
 public ImageEditorInstance!: ImageEditorComponent;
 public toolbarItems: string[] = [];
 public created = (): void => {
  this.ImageEditorInstance.open("http://localhost:6969/image/bridge.png");
 }
 public rotate = (): void => {
  this.ImageEditorInstance.rotate(90);
 }
 public flip = (): void => {
  this.ImageEditorInstance.flip("Vertical");
 }
}

Rotate and Flip Options in Angular Image Editor

Annotations

The Angular Image Editor component supports multiple types of annotations, including text, freehand drawings, and shapes such as rectangles, ellipses, and lines.

Text

You can insert a text annotation and customize it by changing its color, font family, font size, and font styles, such as bold and italic. You can add a text annotation by either using the toolbar or the drawText method.

In the drawText method, you can insert a text annotation by specifying the text, font family, font size, and font styles.

In the toolbar, we can insert a text annotation by just clicking the Annotation dropdown button and picking the Add Text option. Once the text is inserted, the contextual toolbar will be enabled to customize the annotation’s color, font family, font size, and font styles, such as bold and italic.

Shapes

You can insert and customize the shape annotations such as rectangles, ellipses, and lines by changing their stroke color, fill color, and stroke width. Shape annotations can be made by either using the toolbar or the drawRectangle , drawEllipse , and drawLine methods.

In the toolbar , we can insert the shape annotations by clicking the Annotation dropdown button and picking either the Rectangle** , **** Ellipse ***,* or Line options. Once the shape is inserted, the contextual toolbar will be enabled to customize the annotation’s stroke color, fill color, and stroke width.

In the following code example, the drawText method is used to insert text, and the drawRectangle** , **** drawEllipse ***,* and drawLine methods are used to insert the respective annotation shapes.

<div>
 <div style="padding-bottom: 10px;">
  <button class="e-btn" (click)="text()">Add Text</button>
  <button class="e-btn" (click)="rectangle()">Rectangle</button>
  <button class="e-btn" (click)="ellipse()">Ellipse</button>
  <button class="e-btn" (click)="line()">Line</button>
 </div>
 <div id="wrapperDiv" style="width:550px; height:350px;">
  <ejs-imageeditor (created)="created()" #ImageEditor [toolbar]='toolbarItems'></ejs-imageeditor>
 </div>
</div>

export class AppComponent {
 @ViewChild('ImageEditor')
 public ImageEditorInstance!: ImageEditorComponent;
 public toolbarItems: string[] = [];
 public created = (): void => {
  this.ImageEditorInstance.open("http://localhost:6969/image/bridge.png");
 }
 public text = (): void => {
  this.ImageEditorInstance.drawText(50, 50, 'Syncfusion');
 }
 public rectangle = (): void => {
  this.ImageEditorInstance.drawRectangle(50, 300);
 }
 public ellipse = (): void => {
  this.ImageEditorInstance.drawEllipse(1000, 300);
 }
 public line = (): void => {
  this.ImageEditorInstance.drawLine(1000, 150);
 }
}

Text and Shapes Annotation Feature in Angular Image Editor

Freehand drawing

You can easily insert a freehand drawing annotation and customize it by changing its stroke color and stroke width. The freehand drawing annotation can be made by either using the toolbar or the freehandDraw method.

In the toolbar , you can insert the freehand draw annotation by clicking the Annotation dropdown button and picking the Freehand Draw option. Once the freehand draw option is enabled, the contextual toolbar will be enabled to customize the stroke color and width.

In the following code example, the freehandDraw method is used to toggle the freehand drawings.

<div>
 <div style=”padding-bottom: 10px;”>
  <button class=”e-btn” (click)=”freehanddraw()”>Freehand Draw</button>
 </div>
 <div id=”wrapperDiv” style=”width:550px; height:350px;”>
  <ejs-imageeditor (created)=”created()” #ImageEditor [toolbar]=’toolbarItems’></ejs-imageeditor>
 </div>
</div>

export class AppComponent {
 @ViewChild(‘ImageEditor’)
 public ImageEditorInstance!: ImageEditorComponent;
 public toolbarItems: string[] = [];
 public created = (): void => {
  this.ImageEditorInstance.open(“http://localhost:6969/image/bridge.png”);
 }
 public freehanddraw = (): void => {
  this.ImageEditorInstance.freeHandDraw(true);
 }
}

Freehand Drawing Annotation Feature in Angular Image Editor

Zooming and panning an image

The Angular Image Editor allows users to zoom and pan an image. You can perform zooming and panning by either using the toolbar or the zoom and pan method.

In the toolbar , we can perform zooming by clicking the Zoom In and Zoom Out ** buttons, which enable the **Pan option in the toolbar.

In the following code example, the zoomIn** , **** zoomOut ***,* and pan methods are used to perform zooming in, zooming out, and panning the image, respectively.

<div>
 <div style="padding-bottom: 10px;">
  <button class="e-btn" (click)="zoomIn()">Zoom In</button>
  <button class="e-btn" (click)="zoomOut()">Zoom Out</button>
  <button class="e-btn" (click)="pan()">Pan</button>
 </div>
 <div id="wrapperDiv" style="width:550px; height:350px;">
  <ejs-imageeditor (created)="created()" #ImageEditor [toolbar]='toolbarItems'></ejs-imageeditor>
 </div>
</div>

export class AppComponent {
 @ViewChild('ImageEditor')
 public ImageEditorInstance!: ImageEditorComponent;
 public toolbarItems: string[] = [];
 public created = (): void => {
  this.ImageEditorInstance.open("http://localhost:6969/image/bridge.png");
 }
 public zoomIn = (): void => {
  this.ImageEditorInstance.zoom(0.1);
 }
 public zoomOut = (): void => {
  this.ImageEditorInstance.zoom(-0.1);
 }
 public pan = (): void => {
  this.ImageEditorInstance.pan(true);
 }
}

Zooming and Panning Features in Angular Image Editor

Toolbar customization

You can customize the built-in toolbar using the toolbar property. A contextual toolbar is enabled while inserting annotations. You can also customize the toolbar by using the toolbarUpdating event.

In the following code example, the annotate option is only enabled with text, rectangle, and ellipse options using the toolbar property, and the contextual toolbar for the rectangle annotation is rendered with only stroke color by excluding fill color and stroke width using the toolbarUpdating event.

<div>
 <div id=”wrapperDiv” style=”width:550px; height:350px;”>
  <ejs-imageeditor (toolbarUpdating)=”toolbarUpdating($event)” (created)=”created()” #ImageEditor [toolbar]=’toolbarItems’></ejs-imageeditor>
 </div>
</div>

export class AppComponent {
 @ViewChild(‘ImageEditor’)
 public ImageEditorInstance!: ImageEditorComponent;
 public toolbarItems: string[] = [‘Annotate’, ‘Text’, ‘Rectangle’, ‘Ellipse’];
 public created = (): void => {
  this.ImageEditorInstance.open(“http://localhost:6969/image/bridge.png”);
 }
 public toolbarUpdating = (args: ToolbarEventArgs): void => {
  if (args.toolbarType === ‘shapes’) {
   args.toolbarItems = [‘strokeColor’];
  }
 }
}

Customizing the Toolbar in Angular Image Editor

Toolbar template

Also, users can replace the toolbar of the Image Editor with the user-specific UI using the toolbarTemplate property.

Refer to the following code example.

<div>
 <div id="wrapperDiv" style="width: 550px; height: 350px;">
  <ejs-imageeditor (created)="created()" #ImageEditor>
   <ng-template #toolbarTemplate let-data>
    <div style="padding: 10px; border-bottom: 1px solid darkgray;">
     <button class="e-btn" (click)="text()">Add Text</button>
     <button class="e-btn" (click)="rectangle()">Rectangle</button>
     <button class="e-btn" (click)="line()">Line</button>
    </div>
   </ng-template>
  </ejs-imageeditor>
 </div>
</div>

export class AppComponent {
 @ViewChild('ImageEditor')
 public ImageEditorInstance!: ImageEditorComponent;
 public toolbarItems: string[] = ['Annotate', 'Text', 'Rectangle', 'Ellipse'];
 public created = (): void => {
  this.ImageEditorInstance.open("http://localhost:6969/image/bridge.png");
 }
 public text = (): void => {
  this.ImageEditorInstance.drawText(50, 50, 'Syncfusion');
 }
 public rectangle = (): void => {
  this.ImageEditorInstance.drawRectangle(50, 300);
 }
 public line = (): void => {
  this.ImageEditorInstance.drawLine(1000, 150);
 }
}

Customizing the Toolbar with the Toolbar Template Option in Angular Image Editor

Adaptive and touch-friendly UI

By default, the Angular Image Editor adapts to all mobile devices based on the screen size. It is a touch-friendly component, so users can use their finger, a pen, or a mouse device on desktop and mobile devices to edit the image.

Adaptive and Touch-Friendly UI in Angular Image Editor

How to use it

We have a set of resources for you, including our Angular Image Editor live demos and documentation that explains our customization features.

Conclusion

Thanks for reading! We hope you enjoyed this quick introduction to the design and features of our new Angular Image Editor component. If you would like to give it a try, please download the latest available version of Essential Studio, 2022 Volume 3 . Experience wonderful image editing with this component and provide your valuable feedback in the comments section below.

You can also contact us through our support forums, support portal, or feedback portal. We are always happy to assist you!

Related blogs

Deploying a .NET Core Application in Azure Kubernetes

Rajeshwari Pandinagarajan — Thu, 10 Nov 2022 12:43:53 +0000

In development, maintaining the release and deployment workflow is one of the most critical areas of a project. Therefore, many teams like to create an automated deployment workflow to manage their releases and production. Maintaining an automated deployment workflow can be complex, but it will save the team time and effort.

Azure DevOps is one of the best platforms to create an automated CI/CD pipeline for an application, making this job easy. This article will discuss the steps to deploy a .NET Core application in Azure Kubernetes using the Azure DevOps Starter.

Prerequisites

What Are Containers and Container Orchestration?

To understand the functionality of Kubernetes, you must first understand the concepts of containers and container orchestration.

Containers are a form of the virtualized operating system. A container contains all essential executables, binary code, dependencies, and configuration files. A single container can execute anything from a microservice or software process to a considerably large application.

Containers seem to be very scalable since they can be produced as needed. But the complexity increases when you must maintain hundreds or thousands of containers, and it becomes impossible to manage all their lifecycles. This is the situation in which container orchestration comes to the rescue.

Containers’ maintenance, deployment, scaling, and networking can be automated using a container orchestration system. In addition, you can deploy the same application across multiple environments using container orchestration rather than having to redevelop or redesign it.

What Is Kubernetes?

Kubernetes, also known as K8s, is a well-known open-source container management (orchestration) technology for automating applications’ deployment, scaling, and administration.

The Kubernetes orchestration features allow the development of application services that span across many containers, the scheduling of containers in a cluster, the deployment of those containers, and control of the status of the containers over time.

What Is Azure Kubernetes Service?

Developed on top of the open-source Kubernetes technology, Azure Kubernetes Service (AKS) is a managed container orchestration service. You can use AKS to administer your hosted Kubernetes environment and easily launch, scale, and manage containerized apps.

Through on-demand resource provisioning, updating, and scaling, AKS simplifies Kubernetes deployment and operation. It enables you to execute your applications in the cloud while eliminating the complexity and operational burden of Kubernetes management.

In addition, your development and operations teams can collaborate on a single platform using AKS to build and deploy applications more efficiently.

How to Deploy a .NET Core Application in Azure Kubernetes

Step 1: Create an Azure DevOps starter project.

Sign in to your Azure portal, click the Create a resource option, and select DevOps Starter. Then, you’ll be navigated to where you can create the DevOps Starter project. You have to complete four main steps to create the project.

a. Choose the runtime.

Select the .NET runtime, as shown in the following figure, to run the ASP.NET Core application

b. Choose the framework.

Select ASP.NET Core as the framework for the runtime, as shown in the following figure.

c. Choose the service.

Then, select Kubernetes as the Azure service to deploy this application.

d. Create the project with the necessary configurations.

Now, configure the Azure subscription and settings for the Kubernetes cluster. I will explain these configurations in the upcoming step.

Step 2: Configure the subscription and Azure Kubernetes service.

We need to do a few configurations in the fourth part of creating the DevOps Starter project. We’ll use GitHub to create a repository for this project. As shown in the following figure, you need to authorize access to Azure for your GitHub personal account.

There are some other configurations to be done after authorizing the GitHub account. First, select the organization. Here, selects your GitHub account as a personal account. There is a field named Repository in the next figure: use it to add the name of the repository to be created in the GitHub account. This repository will be used to deploy the Azure Kubernetes service. Then, select the subscription for the DevOps Starter project. I will be using the Azure for Students subscription for this demonstration.

Then, create a new cluster or use one you have already created.

If you are going to create a new cluster for this project, first add a name for the cluster. Then, select the location in which to create this service. After, select Standard_B2ms , based on the B-series burstable VMs, as the virtual machine size. Use this VM to create the service for testing and demonstration purposes.

Add additional settings if you need them according to your requirements or subscription plan. For example, if you are using a student subscription, you can adjust the settings as shown in the following image.

The student subscription has some limitations. You have to set the node count to 1 and choose the Basic service tier for the Container Registry SKU, as it is a cost-optimized tier suitable for learning and testing purposes.

Finally, click Review+Create to create the Azure DevOps Starter project, which will deploy the ASP.NET Core application in the Azure Kubernetes service. It will take a few minutes to create the project.

After a few minutes, check your GitHub repository to make sure a new repository was created with the name you provided. You can see the workflow that has been automatically created for the GitHub action. It will be used to automate the CI/CD pipeline. You can also customize it if needed.

The Azure resources and the status of the GitHub workflow will also be visible in the Azure portal after deploying it to the Kubernetes service, as shown in the following image.

Furthermore, you can access the ASP.NET Core application using the external endpoint. There, you will see the application as shown in the following figure.

Step 3: Check the CI/CD pipeline.

Now, check the CI/CD pipeline you created using the Azure DevOps Starter by cloning the ASP.NET Core project to your local machine with the help of the following git command.

git clone {git-repo-link}.git

For the ease of viewing and editing files, let’s use Visual Studio Code 2022 to open the cloned application. Then, open the file named index.html inside the Pages folder.

Then, you can edit it as you need. To demonstrate how the changes will activate the CI/CD pipeline, let’s change the

div element as shown in the following code snippet.

<div class="content-body">
   <div class="success-text">Success!</div>
   <div class="description line-1">GitHub workflow has been successfully setup</div>
   <div class="description line-2">Deploying DotNet Core Application In Azure Kubernetes</div>
</div>

Then, run and check it locally. After that, push the latest changes with a commit. First, add the changes to the staging area.

git add

Second, commit the changes with an appropriate commit message into the local repository.

git commit -m "Update index.html"

Third, push the commits to the GitHub repository.

git push -u origin main

The GitHub action will trigger the build pipeline after successfully pushing the commits.

After completing the build process, it will deploy the application to the Azure Kubernetes service.

You can check your Azure Kubernetes service after deploying the application to it by clicking the external endpoint, as shown in the following figure.

Here, you see that the latest version of the application was deployed successfully to the Azure Kubernetes service.

Conclusion

This article discussed how to deploy an ASP.NET Core app to the Azure Kubernetes service using the Azure DevOps Starter, with the help of GitHub actions, to create an automated CI/CD pipeline for the app. This process eliminates the complexity of the deployment process significantly.

I hope this article will help you in your next project.

The Syncfusion ASP.NET Core UI control library, powered by Essential JS 2, is the only suite you will ever need to build an app. It contains over 70 high-performance, lightweight, modular, and responsive UI controls in a single package. Use them to build stunning web apps!

If you’re already a Syncfusion user, you can download the product setup . If not, you can download a free 30-day trial to evaluate our products.

You can contact us through our support forum, support portal, or feedback portal. As always, we are happy to assist you!

Thank you for reading!

Related blogs

JavaScript Debugging with VS Code and Chrome

Rajeshwari Pandinagarajan — Thu, 10 Nov 2022 11:45:38 +0000

Debugging is a vital part of identifying why your application is misbehaving. We feel great satisfaction once we find the bug in our code and fix it.

No matter how skilled we get as developers, we still have to spend countless hours fixing bugs in our code. Thus, we should work on improving our debugging skills. If you work with JavaScript, you know it is not always cooperative. Fortunately, several JS debugging tools are accessible, usually making troubleshooting straightforward.

This article will discuss how we can debug JavaScript using the simple and efficient tools in Visual Studio Code and Google Chrome.

Debugging Methods for JavaScript

Breakpoints

A breakpoint is where a line of code causes the debugger to pause JavaScript execution. We can examine current variables and run commands in the console while the code is paused. To put it another way, we can debug it. A list of breakpoints is always available in the right panel of Chrome DevTools. This is useful when we have a lot of breakpoints in different files.

Debugger Keyword

In JavaScript, we can also use the debugger keyword. The keyword causes code execution to pause. However, the browser will ignore such a command unless the development tools are open. See the following example.

function writefunction() 
{
  console.log("Stop Executing write function!");
  debugger; // <-- the debugger stops here
}
helloWorld();

Backtracking

Backtracking is the process of applying potential solutions to a problem in a JavaScript program. The procedure begins at the location where a specific error is discovered. From there, the complete source code is traced backward. The stages involved in this are:

Identify the callers of each function.
Determine whether any issues connected to that function have occurred there.

If not, you go back to the caller of that function. If it doesn’t work, you retreat and try again.

Keep repeating this until the error is removed and the expected output is obtained.

Strict Mode

Using JavaScript’s strict mode makes writing standardized and readable JavaScript programs easier. We can put a program under a strict operating perspective by using strict mode. This strict context forbids specific actions and throws exceptions. It helps reduce bugs and keep the code clean. For example, JavaScript will throw an error in strict mode if we assign values to undeclared variables. The use strict statement enables the strict mode.

Debugging JavaScript in VS Code

VS Code provides easy and straightforward solutions for debugging. Visual Studio Code debuggers support many languages and platforms, which are either built-in or accessed by extensions. Let’s work on VS Code debugging with sample JavaScript code.

const hotels = [];
export function addHotel(hotel, stars) 
{
    const id = ++hotels.length;
    let numType = 'odd';
    if (id % 2) 
    {
        numType = 'even';
    }
    hotels.push({ id, hotel, stars, numType, });
}

In this example, you will notice some common bugs. Let’s ignore them for now and add some lines to test the code manually.

addHotel('Kingsburry', '5');
addHotel('Hilton', '5');
addHotel('Cinnamon Grand', '5');

Now, let’s use VS Code’s built-in *breakpoints * to break the program’s execution wherever we want to test when the bugs occur.

We discussed breakpoints. As you can see in the previous code, the red dots on the left side of VS Code editor are the breakpoints. You can add these by clicking on the panel to the left of the line numbers. Then, on the action bar, click the debug icon.

Take a look at the top section. You will notice a gear icon. Click it. A debug configuration file named launch.json will be prompted. Update the configuration with reference to the following code to enable the VS Code debugger on App.js.

"configurations": [
   {
      "type": "node",
      "request": "launch",
      "name": "Launch App",
      "program": "${workspaceFolder}\\debugapp\\src\\App.js"
   }
]

Now, click the play icon at the top of the debugger panel. A toolbar will appear at the top of the VS Code. The toolbar will contain several icons you can use to manipulate the debugging process.

In the previous screenshot, you’ll notice that the debugger has paused on your first breakpoint. To continue the session, press the play icon, which will cause execution to continue until it reaches the next breakpoint. Clicking the play icon again will finish the execution and end the debugging session. Let’s understand what the sections on the left pane provide us with:

Variables : displays the current scope’s local and global variables (at the point of execution).
Watch: you can manually enter expressions for variables you want to monitor.
Call Stack: displays the highlighted code’s call stack.
Breakpoints: shows a list of files with breakpoints and their line numbers.

Debug with Watch

The watch panel tracks expressions in our code. The expression will be evaluated on whether it satisfies the criteria set here. You can watch a new expression by clicking the + in the panel and entering an expression.

Conditional Breakpoints

Watching variables alone isn’t always enough. For example, say we wish to pause the debugging only if a specific requirement is met. Add a standard breakpoint to accomplish this. After adding the breakpoint, right-click on it, choose Edit Breakpoint , and add the conditional statement expression for which you need to pause the debugging.

Call Stack

The call stack helps trace exceptions and determine who called what. You can select an item listed in this pane to see who called it.

Another tool in your VS Code toolbox for debugging is using the debug console. Although it may occasionally be excessive, it will frequently save you time when looking for bugs.

Debugging JavaScript with Google Chrome

The majority of IDEs and almost all recent browsers include debugging tools, which makes debugging much more straightforward. The browsers also allow for step-by-step code tracing to pinpoint the exact cause of the error. Google Chrome, which many developers use, provides us with debugging solutions for JavaScript. In addition, Chrome provides debugger extensions for VS Code and Chrome DevTools. Chrome DevTools comes built-in with the Google Chrome browser.

Chrome Debugger for VS Code

Chrome’s debugger helps debug client-side JavaScript code, which runs in Google Chrome straight from VS Code. The Chrome debugger is an extension that needs to be installed in VS Code.

The debugger usually connects to Chrome over its Chrome Debugger Protocol, where files loaded in the browser are mapped to the files opened in VS Code. You can set breakpoints directly in the source code and set up variables to watch along with the entire call stack when debugging without leaving the editor.

Due to the inclusion of a JavaScript debugger in Visual Studio Code, this extension is no longer supported (deprecated) there. The JavaScript debugger fixes problems with Node.js, Chrome, Edge, WebView2, VS Code extensions, and other programs. You can remove the Chrome debugger extension without risk and still have access to the required capabilities.

Chrome Developer Tools

The finest debugging tool is already included with your Chrome browser, whether you’re working with Angular, React, or Vue applications. The Google Chrome browser includes developer tools (also known as DevTools) that allow developers to edit code directly in the browser, add breakpoints to detect issues, and debug their code more quickly.

To open the DevTools Elements panel, press Command + Option + C on a Mac or CTRL + SHIFT + C on any other operating system.

Let’s review some practical strategies for debugging your code more efficiently with DevTools.

Adding Breakpoints in DevTools

Navigate to the Sources tab in the DevTools.
In the navigation panel on the left side, select the .js file. The code of the selected .js file will be displayed in the middle panel.
Right-click on the line where you want to add the breakpoint. Then, in the dropdown list, select Add breakpoint. A blue color breakpoint will be displayed, as shown in the following image. When we rerun the execution, the execution will pause at the breakpoint. Instead of console.log(something) and reloading pages, pause and inspect the code. It’s a more productive way to debug. When everything appears in order, click the resume button on the page to proceed with the execution. DevTools allows you to add a variety of breakpoints. The following image summarizes all the available breakpoint types.

Create/Save/Run Snippets

Utilizing snippets is an additional effective method for debugging. Using snippets, you may quickly run and reuse scripts in any area of your app.

To add a snippet:

Select Snippets in the left panel.
Click *New Snippet * in the left panel and write your code in the middle panel.
Save your snippet with keyboard commands (CTRL+C on Windows).
To run this code, right-click on the snippet and select Run.

DevTools Call Stack

You can also use DevTools to view the call stack. This is helpful when you’re troubleshooting errors and you need to keep track of changes to the call stack due to many asynchronous methods. Expand the Call Stack panel in the right panel to examine all the current functions in the call stack. This is available in the Sources tab of the DevTools.

Changes to Variables

Suppose you have a bug that does not return the correct value for a variable, and you want to check its value at a specific point in a function:

Add a breakpoint.
Navigate to the appropriate panel.
Expand the Scope to see the value of the variable.

You can see that this panel contains a lot of helpful information for troubleshooting bugs.

You can edit the variables by double-clicking them to test the function with different values.

Blackboxing

At times, you might need to prevent some scripts from running while debugging. You can black box them in DevTools rather than commenting them out in your code. Click on the script file you want to ignore in the Sources tab’s left panel. To add a script to the ignore list, right-click the code in the middle panel and choose Add script to ignore list.

Since the DevTools won’t execute this script, you can concentrate more on studying the flawed code and identifying the bug.

Benefits of Having a Debugger Tool

DevTools in Google Chrome is a terrific resource for debugging, enhancing network speed, viewing your site in various screen sizes and resolutions, and learning where you can improve the code. Even if Google Chrome is not your regular browser, installing it is highly recommended so you can use these features.

Saves time: The debugger helps enhance the speed of software development by providing many tools to keep track of the code and ensure the application’s behavior.

Reports errors: As soon as an error occurs, the debugger tool reports it. This makes the software development process less stressful and enables the early detection of errors.

Straightforward interpretations: By providing more details on data structures, the debugger tools enable simple interpretations.

Bug-free software: It assists developers in discovering software bugs so that they can be repaired before the software’s release.

Wrap Up

In this article, we went through the different techniques of debugging JavaScript code and the tools used in VS Code and Google Chrome.

VS Code’s debugging tools and Chrome’s DevTools offer significant functionality for debugging JavaScript. You’ll become a more effective debugger once you’ve mastered these tools and your days of unending console.log() will be over.

Thanks for reading. I hope this article helped with the critical concepts of debugging JavaScript.

Syncfusion’s Essential JS 2 is the only suite you will need to build an app. It contains over 65 high-performance, lightweight, modular, and responsive UI components in a single package. Download a free trial to evaluate it today.

If you have any questions or comments, you can contact us through our support forums, support portal, or feedback portal. We are always happy to assist you!

Related blogs

Syncfusion Mobile and Desktop Controls are Now Compatible with .NET 7

Rajeshwari Pandinagarajan — Wed, 09 Nov 2022 11:00:13 +0000

We have released a service pack for our 2022 Volume 3 release of Essential Studio. We are excited to announce that with this service pack release, our mobile and desktop controls for .NET MAUI, WPF, WinUI, and WinForms are now compatible with .NET 7.0.

Our .NET MAUI components are compatible with the following development environments:

Microsoft Visual Studio 2022 17.4.0 Preview 6.0 (.NET MAUI version 6.0.541) with .NET 7.0.
Microsoft Visual Studio 2022 17.4.0 Preview 6.0 (.NET MAUI version 6.0.541) with .NET 6.0.
Microsoft Visual Studio 2022 17.4.0 (.NET MAUI version 6.0.541) with .NET 6.0.
Visual Studio 2022 for Mac 17.4 Preview with .NET 6.0.

You can create projects targeting .NET 7.0 and reference our service pack NuGet packages either from nuget.org, or you can use the installer available from the Syncfusion website. Depending on your license, you can download the licensed installer or try our trial installer.

As you may know, Syncfusion is sponsoring the upcoming .NET Conf 2022, a free virtual event on November 8–10. The focus of this virtual event is the launch of .NET 7, including updates for .NET MAUI.

.NET MAUI is new, and it has all the right tool sets for building enterprise-quality applications. The top priority for this release of .NET MAUI is increasing the overall quality and reliability of the toolkit.

Referencing the blog announcing .NET 7 RC1, we encourage you to try the listed features using our controls in .NET 7.0 and let us know how it goes.

If you have any questions or comments, you can reach us through our support forum, support portal, or feedback portal. We are always happy to assist you!

Related blogs

Introducing the New Angular Mention Component

Rajeshwari Pandinagarajan — Tue, 08 Nov 2022 11:00:03 +0000

We are happy to introduce the new Angular Mention component in our 2022 Volume 3 release. It provides one of the most anticipated features for all our editor components.

Let’s explore the Angular Mention component, its UI design, and its features with code examples.

Overview

The new Angular Mention component provides @mention and #hashtag functionality for any editor control. It lets users tag or select a user or group name from a suggestion list. It has several out-of-the-box features such as data binding, grouping, UI customization, accessibility, and more.

Key features

The following are the key features of the Angular Mention component:

Data binding.
Mention character customization.
Highlighting for matched text.
Icons paired with suggestion list items.
Categorizable suggestion lists.
Sortable suggestion lists.
UI customization with templates.
Web accessibility and keyboard support.

Data binding

The Angular Mention component supports different types of data sources, such as arrays of primitive data, JSON data collections, and remote data sources using adapters such as OData, OData V4, URLs, JSON, and web APIs.

The following code example shows how to bind a string of array data.

[app.component.ts]

import { Component } from ‘@angular/core’;

@Component({
 selector: ‘app-root’,
 // Specifies the template string for the Mention component.
 Template: `<div id=”commentBox” placeholder=”Type @ and tag user” ></div><ejs-mention [dataSource]=’userData’ [target]=’commentTarget’></ejs-mention>`
})
export class AppComponent {
 constructor() {
 }
 // Defines the array of data.
 Public userData: string[] = [‘Selma Rose’, ‘Russo Kay’, ‘Camden Kate’, ‘Garth’, ‘Margaret’, ‘Robert’, ‘Albert’, ‘Michael’];
 // Sets target editor or editable element.
 Public commentTarget: string = ‘#commentBox’;
}

Customize mention character

You can easily customize the mentioned character using the mentionChar property. Then, you can show or hide the mentioned character while tagging or selecting items by using the showMentionChar property. You can also use multiple mention characters that correspond to different suggestion lists within a single editor.

Customizing the Mention Character in the Angular Mention Component

Note: For more details, refer to our multiple suggestion list example for the Angular Mention component.

Highlight the matched text

The Angular Mention component has the option to configure different visual appearances for the matching text of each suggestion through the highlight property.

Highlighting the Matched Text in the Angular Mention Component

Suggestion list items with icons

The Angular Mention component comes with built-in icon support for visual representations of the suggestion items. To enable this feature, configure the CSS class name through the data source and map the fields.iconCss property for each item.

Angular Mention Component Showing the Suggestion List Items with Icons

Categorize the suggestions list items

You can organize suggestions into groups based on different categories. The category for each list item can be mapped through the groupBy field in the data source.

Categorizing the Suggestion List Items in the Angular Mention Component

Sorting the suggestions list items

The Angular Mention component has built-in support to display the suggestion list items in ascending or descending order using the sortOrder property.

UI customization with templates

To create custom user experiences, use the template option in the Angular Mention component. You can customize the suggestion list items, selection display text, no-record display, and data loading spinner using the template support.

Customizing the Angular Mention Component UI with Templates

Note: For more details, refer to the example for the Angular Mention component template.

Web accessibility and keyboard support

The Angular Mention component supports keyboard interaction and web accessibility standards based on the WAI-ARIA specifications, roles, and states. The supported keyboard shortcuts are as follows:

Down arrow : After the pop-up list opens, press the Down arrow key to move to the next list item. If it is the last item, then the selection will focus on the first item in the list.
Up arrow : After the pop-up list opens, press the Up arrow key to move to the previous list item. If it is the first item, then the selection will focus on the last item in the list.
Home/Page up: Moves to the first item in the list after the pop-up list opens.
End/Page down : Moves to the last item in the list after the pop-up list opens.
Esc : Closes the pop-up list if it is in the open state.
Enter : Selects the focused item, and when the pop-up list is in an open state it closes.
Tab : Focuses on the next TabIndex element on the page when the pop-up list is closed. Otherwise, inserts the selected pop-up list item and close the pop-up list.

How to use it

You can include the Mention component in the rich text editor, text area, text box, or other editable components. It has a huge set of resources for developers, including source code on GitHub, live demos, and thoroughly explained customization features in its documentation.

Supported platforms

The Mention component is also available on the following platforms.

Platform	Live demos	Documentation
React	React Mention demos	Getting started with React Mention
Vue	Vue Mention demos	Getting started with Vue Mention
JavaScript	JavaScript Mention demos	Getting started with JavaScript Mention
ASP.NET Core	ASP.NET Core Mention demos	Getting started with ASP.NET Core Mention
ASP.NET MVC	ASP.NET MVC Mention demos	Getting started with ASP.NET MVC Mention

Conclusion

Thanks for reading! In this blog, we have seen the features of the new Angular Mention component that rolled out in our 2022 Volume 3 release. These features are also listed on our Release Notes and the What’s New pages. Try out the component and share your feedback as comments on this blog.

You can also reach us through our support forums, support portal, or feedback portal. We are always happy to assist you!

Related blogs

Handling CSV Files in ASP.NET Core Web APIs

Rajeshwari Pandinagarajan — Wed, 02 Nov 2022 10:40:14 +0000

Handling CSV files can be essential for developers in applications using ASP.NET Core Web APIs. There are many approaches to handling CSV, and CSVHelper is a handy NuGet package for doing so easily. This article will discuss how to handle CSV files using the CSVHelper library in an ASP.NET Core Web API.

Prerequisites

Before creating the application, you need to have the following tools installed:

What is CSVHelper?

CSVHelper is an open-source .NET library for reading and writing CSV files. It is speedy, flexible, and easy to use. We can read and write CSV files using the model class. Also, some configurations can map the model class with the headers of the CSV files, if required.

Creating the ASP.NET Core Web API application

First, create an ASP.NET Core Web API project using Visual Studio 2022. To do so, open Visual Studio and select a new project with an ASP.NET Core Web API template, as in the following figure.

Now, select the .NET 6 framework for this project, like in the next figure. Then, create the project and run it to check if everything is working.

Installing the CSVHelper package

Then, to install the CSVHelper package in our project, click right on the project and select the Manage NuGet Packages… option, as shown in the figure.

Then, navigate to the Browse tab in the NuGet section, search for the CSVHelper version 28.0.1 package, and install it, like in the following figure.

Now, create a model class named Employee. This class is used to read and write CSV files.

public class Employee
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int Age { get; set; }
    public string City { get; set; }
    public string JobPosition { get; set; }
}

Note: We have created the Employee model class only for demonstration purposes. You can use any model class you need for your project.

Reading CSV files using CSVHelper

Now, we create a service to read CSV files using the CSVHelper NuGet package. For this, create a folder named Services in the root directory. Then, create an interface named ICSVService , similar to the next sample.

public interface ICSVService
{
   public IEnumerable<T> ReadCSV<T>(Stream file);
}

Create a class named CSVService, inherited from ICSVService.

public class CSVService : ICSVService
{
    public IEnumerable<T> ReadCSV<T>(Stream file)
    {
        var reader = new StreamReader(file);
        var csv = new CsvReader(reader, CultureInfo.InvariantCulture);

        var records = csv.GetRecords<T>();
        return records;
    }
}

We have used a method-level generic to deal with the model class. We can use this method with any model class to read CSV files. We have also passed the file stream as a parameter to the ReadCSV method. The StreamReader reads the text and characters from the file stream. Later, we used CsvReader to transfer the content read from StreamReader into the memory. Then, the GetRecords method returned the data of CSV files. We don’t need any configurations if our class property names match the headers of CSV files.

After all this, register the CSV service in the Program.cs, as shown in the next code.

builder.Services.AddScoped<ICSVService, CSVService>();

Next, create a controller class named EmployeeController inside the Controllers folder. Then, create the HttpPost request to read the CSV file using the ICSVService.

[ApiController]
[Route("[controller]")]
public class EmployeeController : Controller
{
   private readonly ICSVService _csvService;

   public EmployeeController(ICSVService csvService)
   {
       _csvService = csvService;
   }

   [HttpPost("read-employees-csv")]
   public async Task<IActionResult> GetEmployeeCSV([FromForm] IFormFileCollection file)
    {
        var employees = _csvService.ReadCSV<Employee>(file[0].OpenReadStream());

        return Ok(employees);
    }
}

We injected the ICSVService to use the read operation for CSV files. Also, EmployeeController uses the ApiController attribute to implement the Web API controller in ASP.NET Core. Then, we used the ReadCSV method of the CSVService to get the data of the CSV file after reading it.

First, let’s run the application. The following is the screenshot of the CSV file we use to read the data.

Then, run the read-employees-csv endpoint to read the CSV file like in the following figure.

Here we have attached the CSV file we use to run the read.

We received a response after running the API successfully.

Writing CSV files using CSVHelper

We use CSVService to create a CSV write method using the CSVHelper. For this, add an abstract method named WriteCSV in the ICSVService interface.

public interface ICSVService
{
    public IEnumerable<T> ReadCSV<T>(Stream file);
    void WriteCSV<T>(List<T> records);
}

After that, implement the WriteCSV method in the CSVService class like in the following code.

public class CSVService : ICSVService
{
    public IEnumerable<T> ReadCSV<T>(Stream file)
    {
        var reader = new StreamReader(file);
        var csv = new CsvReader(reader, CultureInfo.InvariantCulture);

        var records = csv.GetRecords<T>();
        return records;
    }

    public void WriteCSV<T>(List<T> records)
    {
        using (var writer = new StreamWriter("D:\\file.csv"))
        using (var csv = new CsvWriter(writer, CultureInfo.InvariantCulture))
        {
            csv.WriteRecords(records);
        }
    }
}

In the WriteCSV method, the StreamWriter is used to create and write files in the path specified in the parameter. The CsvWriter is used to create the actual CSV files using the StreamWriter instance created. The WriteRecords method writes all the data into the files.

Now, use EmployeeController to create a HttpPost request to create and write the CSV file.

[ApiController]
[Route("[controller]")]
public class EmployeeController : Controller
{
    private readonly ICSVService _csvService;

    public EmployeeController(ICSVService csvService)
    {
        _csvService = csvService;
    }

    [HttpPost("write-employee-csv")]
    public async Task<IActionResult> WriteEmployeeCSV([FromBody] List<Employee> employees)
    {
        _csvService.WriteCSV<Employee>(employees);

        return Ok();
    }

    [HttpPost("read-employees-csv")]
    public async Task<IActionResult> GetEmployeeCSV([FromForm] IFormFileCollection file)
    {
        var employees = _csvService.ReadCSV<Employee>(file[0].OpenReadStream());

        return Ok(employees);
    }
}

We implemented the new HttpPost request to write the CSV files using the WriteCSV method of CSVService.

Let’s run the Web API application. Then, we run the write-employee-csv endpoint to test the service.

We used Swagger to run and test the API to write the CSV. We passed a list with two employee objects.

And so, we have successfully created a CSV file in the directory path. The employee data is in the CSV file, like in the next figure.

Conclusion

This article discussed handling CSV files using the CSVHelper package with an ASP. NET Core Web API application. This included performing read and write operations in the CSV file using the CSVHelper package.

I hope this article will help you handle your next project’s CSV files. Thank you for reading.

If you’re already a Syncfusion user, you can download the product setup. If not, you can download a free 30-day trial to evaluate our products.

You can contact us through our support forum, support portal, or feedback portal. As always, we are happy to assist you!