SDK: Define Public API in client SDK

[rjvelazco]

Parent Issue

#30943

Overview

Currently, our NPM package lacks clear organization regarding which utility functions, constants, and helpers are meant for public use versus internal use. This lack of structure can lead to confusion and misuse of internal functions. To address this, we need to revisit our exports, create a public_api file, and ensure only necessary functions and utilities are exposed to the end users.

Task

Tasks

Preview Give feedback

1. Define what will stay in the @dotcms/client and what will be moved to @dotcms/uve.
2. Create a document to justify why each function, constant, or utility is exported or kept internally.
3. A comprehensive list of all utility functions, constants, and helpers, categorized into Public API and Internal.
4. The public API is well-documented, including usage examples and explanations.
5. Updated package documentation to clearly define and explain the public API.

Proposed Objective

Core Features

Proposed Priority

Priority 3 - Average

Acceptance Criteria

1. Identify which methods will remain in the @dotcms/client SDK and which will move to @dotcms/uve.
2. Create a uve-api.ts and add there all the content that will be moved in the new @dotcms/uve.
3. Add internal aliases to facilitate easier development.
4. Make sure to not break current implementations
5. Keep exporting clients' actions to not break customers' implementation

Assumptions & Initiation Needs

• A clear understanding of which functions and utilities are intended for public use versus internal use.
• Collaboration with the development team to ensure accurate classification and refactoring.

Quality Assurance Notes & Workarounds

• Verify that the package's public API is accessible and functions correctly in various environments (e.g., Node.js, browser).
• Ensure internal utilities are not exposed or accessible through the package's public API.
• Test the package with existing projects to check for any unexpected regressions or issues.
• Ensure that all public API changes are backward compatible or properly documented if breaking changes are unavoidable.

[fmontes]

Here is where the split client/editor might happen... what do you think in turning this into an spike and based on the results create the tickets for the split/organization. This will be a big API decision that can't be taken by one person.

[rjvelazco]

Absolutely, @fmontes. We can turning this into a Spike. A significant part of the task in this ticket is to identify, document, and discuss the results with the team.

I already have the ticket for the Split here: #31158. I will update that and leave this one solely for Spike/Research.