@cdmbase/wiki-browser 12.0.18-alpha.5

package/lib/templates/content/docs/intl/intl-namespace.md

@@ -0,0 +1,129 @@
+---
+meta:
+    title: Translations Namespaces
+    description: Translations Namespaces
+date: '2023-06-02T00:00:00'
+updated: '2024-06-02T00:00:00'
+excerpt: Translations Namespaces...
+headers:
+    Cache-Control: no-cache
+---
+
+## Translations Namespaces
+
+To maintain a consistent, organized, and scalable approach to naming translation keys in your React components, we ask developers to follow a specific naming convention. This helps ensure that all translation keys are easily understandable and maintainable. Here’s how to structure your translation keys:
+
+### Guidelines
+
+1. **Use Unique Prefixes for Each Module**
+    - Ensure each module has a unique prefix. This helps avoid conflicts when translation keys are similar across different modules.
+    - Example: Use `user.profile.name` and `admin.profile.name` instead of just `profile.name`.
+
+2. **Consistent Naming Convention**
+    - Stick to a consistent naming convention across all files. This includes using lower case, underscores or dots for separating words, and descriptive names.
+    - Example: Use `user.settings.update_email` instead of `UserSettings_UpdateEmail`.
+
+3. **File-Based Namespacing**
+    - Divide translation files by modules and features. Each file should represent a specific module or feature.
+    - Example:
+        - `user.json` for user-related translations.
+        - `admin.json` for admin-related translations.
+        - `dashboard.json` for dashboard-related translations.
+
+4. **Avoid Generic Names**
+    - Avoid using generic names for keys that might be reused across different modules.
+    - Example: Use `dashboard.header.title` instead of `header.title`.
+
+5. **Centralized Key Registry**
+    - Maintain a centralized registry of translation keys to track and manage the keys used across the project.
+    - Use tools or scripts to check for duplicate keys and ensure consistency.
+
+6. **Environment-Based Namespacing**
+    - If translations are environment-specific, include the environment in the key.
+    - Example: Use `dev.user.profile.name` and `prod.user.profile.name`.
+
+7. **Version Control and Review Process**
+    - Implement a version control system for translation files.
+    - Establish a review process for adding new keys to ensure consistency and avoid conflicts.
+
+8. **Use Contextual Information**
+    - Add contextual information to translation keys to make their purpose clear.
+    - Example: Use `button.submit_form` instead of just `submit`.
+
+9. **Document Translation Key Patterns**
+    - Document the patterns and conventions used for naming translation keys in the project's README or a dedicated document.
+
+10. **Fallback Strategy**
+    - Implement a fallback strategy for missing translations, specifying default values or default languages.
+
+### Example of Structured Translation Files
+
+#### user.json
+
+```json
+{
+    "user": {
+        "profile": {
+            "name": "Name",
+            "email": "Email",
+            "update_button": "Update Profile"
+        },
+        "settings": {
+            "update_email": "Update Email",
+            "change_password": "Change Password"
+        }
+    }
+}
+```
+
+#### admin.json
+
+```json
+{
+    "admin": {
+        "dashboard": {
+            "title": "Admin Dashboard",
+            "user_management": "User Management"
+        },
+        "settings": {
+            "site_configuration": "Site Configuration",
+            "manage_roles": "Manage Roles"
+        }
+    }
+}
+```
+
+#### dashboard.json
+
+```json
+{
+    "dashboard": {
+        "header": {
+            "title": "Dashboard",
+            "welcome_message": "Welcome to your dashboard"
+        },
+        "statistics": {
+            "total_users": "Total Users",
+            "active_sessions": "Active Sessions"
+        }
+    }
+}
+```
+
+## Below note is internal to Admins
+
+### Merging Translation Files
+
+When merging translation files, ensure that:
+
+1. **Consistent Naming**: Ensure that all keys follow the consistent naming convention.
+2. **Unique Namespacing**: Verify that the keys have unique namespaces to prevent conflicts.
+3. **Centralized Registry Check**: Cross-check the centralized registry to ensure no duplicates.
+
+### Review Process
+
+1. **Automated Scripts**: Use automated scripts to check for duplicate keys.
+2. **Peer Review**: Implement a peer review process for adding or modifying translation keys.
+3. **Testing**: Test the merged files in different environments to ensure no conflicts.
+
+By following these additional standards and best practices, you can effectively manage and avoid conflicts when merging multiple translation files, ensuring a seamless and organized translation process.

package/lib/templates/content/docs/intl/vite-plugin-intl.md

@@ -0,0 +1,87 @@
+---
+meta:
+    title: Internationalization
+    description: Internationalization
+date: '2023-06-02T00:00:00'
+updated: '2024-06-02T00:00:00'
+excerpt: Internationalization...
+headers:
+    Cache-Control: no-cache
+---
+
+## Internationalization
+
+For internationalization we are using `i18nInternationalizationPlugin` from common-stack (`@common-stack/rollup-vite-utils`)
+
+# Usage And Implementation
+
+Each package has to define its own localization files inside folder `cdm-locales` . The directory would look something like this
+
+`cdm-locales/en/translations.json`
+
+where translations.json is the namespace. Once defined, the vite plugin will combine all the localization files and will generate files in `frontend-server/public/cdm-locales` folder having all the localization files data for each namespace combined, make sure to use the rollup copy plugin in rollup config of each package so that `cdm-locales` folder of that package is copied as it is to `lib`.
+
+```
+import { copy } from '@web/rollup-plugin-copy';
+
+copy({ patterns: '**/cdm-locales/**/*', rootDir: './src' })
+```
+
+-> Declare plugin in frontend-server `vite.config.js`
+
+```
+import { i18nInternationalizationPlugin } from '@common-stack/rollup-vite-utils'
+
+i18nInternationalizationPlugin({folderName: 'cdm-locales',
+    packages: ['@adminide-stack/*-browser','@adminide-stack/*-ant'],
+    namespaceResolution:  'basename',
+}),
+```
+
+-> Add `cdm-locales ` folder inside each package where internationalization is required.
+
+-> Add respective en, es or any other local translations. The folder structure would look like this
+`cdm-locales/en/translations.json`
+`cdm-locales/en/common.json`
+`cdm-locales/es/translations.json`
+
+-> Using hook `useTranslation` we can use the localization in our components
+` const {t} = useTranslation()`
+
+`t('profile.name', {defaultValue:  'Hello world'})`
+
+## Namespaces
+
+Namespaces are cool way to divide you translation into multiple files. Lets say for instance you want to provide a separate translation file for errors and validation you could add a separate namespace for it. By default we are using common name space that's why our translation files are named `common.json` if you want to add another namespace, you can add another file in cdm-locales folder of respective project for each locale like this `cdm-locales/en/validation.json`.
+
+-> To switch to above namespace you can declate `useTranslation` like this
+` const {t} = useTranslation('validation')`. Then all the translation would be taken from translation.json namespace file
+
+-> Inorder to load the translation file of particular namespace for particular route during SSR you can export handle function similar to loaders and action like this
+
+`export let handle = {
+    i18n: "validation",
+};`
+
+## Examples
+
+- Directory
+
+    ![cdm-locales](/assets/images/cdm-locales-directory.png)
+
+- Copy Plugin
+
+    ![vite-plugin-config](/assets/images/copy-plugin.png)
+
+- Plugin Config
+
+    ![vite-plugin-config](/assets/images/vite-plugin-config.png)
+
+## About i18nInternationalizationPlugin
+
+We are using `i18nInternationalizationPlugin` from common-stack (`@common-stack/rollup-vite-utils`). The purpose of this plugin is to combine the localization files across different packages present inside the node_modules, we can pass the glob pattern to packages key that this plugin accepts and it will automatically match all packages inside the node_modules matching that pattern and will look into lib directory of those packages. If it finds the `cdm-locales` or a folder defined by `folderName` key, it will fetch the locales files from that folder and will merge the files of different packages into one and will generates files in `frontend-server/public/cdm-locales` which holds all the localization data of each namespace combined, which is then served as resources to i18next.
+
+`i18nInternationalizationPlugin({folderName: 'cdm-locales',
+    packages: ['@adminide-stack/*-browser','@adminide-stack/*-ant'],
+    namespaceResolution:  'basename',
+}),`

package/lib/templates/content/docs/intl/webpack-plugin-intl.md

@@ -0,0 +1,12 @@
+---
+meta:
+    title: Webpack Plugin Intl
+    description: Webpack Plugin Intl
+date: '2023-06-02T00:00:00'
+updated: '2024-06-02T00:00:00'
+excerpt: Webpack Plugin Intl...
+headers:
+    Cache-Control: no-cache
+---
+
+## Webpack Plugin Intl

package/lib/templates/content/docs/intro.md

@@ -0,0 +1,18 @@
+---
+meta:
+    title: Introduction
+    description: Introduction
+date: '2023-06-02T00:00:00'
+updated: '2024-06-02T00:00:00'
+excerpt: Introduction...
+headers:
+    Cache-Control: no-cache
+---
+
+## Introduction
+
+# Introduction
+
+Welcome to the CDE Basae Wiki. These pages are primarily intended for developers who working in CDEBase projects.
+
+## Getting Started with CDE Base Code

package/lib/templates/content/docs/knowledge/basic-fullstack.md

@@ -0,0 +1,238 @@
+# Developer Documentation Guide
+
+This guide provides essential concepts and resources for developers working with our TypeScript/Apollo GraphQL stack. Each section includes detailed explanations and links to comprehensive documentation.
+
+## Core Concepts
+
+### Object-Oriented Programming (OOP) in TypeScript
+
+**What it is:** Fundamental programming paradigm using classes, inheritance, encapsulation, and polymorphism in TypeScript.
+
+**Why it matters:** Provides structure, reusability, and maintainability to your codebase. Essential for building scalable applications with clear architectural patterns.
+
+**Key topics covered:**
+
+- Classes and interfaces in TypeScript
+- Inheritance and composition patterns
+- Encapsulation and access modifiers
+- Polymorphism and method overriding
+- TypeScript-specific OOP features
+
+**📖 Learn more:** [Object-Oriented Programming in TypeScript](https://www.freecodecamp.org/news/learn-object-oriented-programming-in-typescript/)
+
+---
+
+### Dependency Injection with InversifyJS
+
+**What it is:** A design pattern that provides dependencies to a class rather than having the class create them internally.
+
+**Why it matters:** Improves testability, reduces coupling, and makes your code more modular and maintainable. Essential for creating loosely coupled, testable applications.
+
+**Key topics covered:**
+
+- Inversion of Control (IoC) principles
+- Container configuration and binding
+- Decorator-based dependency injection
+- Testing with mocked dependencies
+- Advanced binding scenarios
+
+**📖 Learn more:** [InversifyJS Documentation](https://github.com/inversify/InversifyJS)
+
+---
+
+## Frontend Development
+
+### Apollo Client Overview
+
+Apollo Client is a comprehensive state management library for JavaScript that enables you to manage both local and remote data with GraphQL. It's the foundation of our frontend data layer.
+
+### Optimistic UI Updates
+
+**What it is:** A pattern where the UI immediately reflects the expected result of a mutation before the server responds.
+
+**Why it matters:** Provides instant feedback to users, making your application feel faster and more responsive. Critical for creating smooth user experiences.
+
+**Key topics covered:**
+
+- Implementing optimistic responses
+- Handling optimistic update failures
+- Best practices for different mutation types
+- Error handling and rollback strategies
+
+**📖 Learn more:** [Optimistic UI with Apollo Client](https://www.apollographql.com/docs/react/performance/optimistic-ui)
+
+---
+
+### Client-Side Schema
+
+**What it is:** Extending your GraphQL schema with client-only fields and types that exist purely on the frontend.
+
+**Why it matters:** Allows you to manage local state using the same GraphQL patterns as remote data, creating a unified data layer.
+
+**Key topics covered:**
+
+- Defining client-side schema extensions
+- Local resolvers implementation
+- Combining remote and local data
+- Type safety with client fields
+
+**📖 Learn more:** [Client-Side Schema](https://www.apollographql.com/docs/react/local-state/client-side-schema)
+
+---
+
+### Offset-Based Pagination
+
+**What it is:** A pagination strategy using offset and limit parameters to fetch specific ranges of data.
+
+**Why it matters:** Essential for handling large datasets efficiently. Provides predictable pagination behavior for tables and lists.
+
+**Key topics covered:**
+
+- Implementing offset-based pagination
+- Cache management for paginated data
+- Performance considerations
+- UI integration patterns
+
+**📖 Learn more:** [Offset-Based Pagination](https://www.apollographql.com/docs/react/pagination/offset-based)
+
+---
+
+### Key Arguments in Pagination
+
+**What it is:** Configuration that tells Apollo Client which arguments should be considered when caching paginated queries.
+
+**Why it matters:** Ensures proper cache behavior when the same query is used with different pagination parameters or filters.
+
+**Key topics covered:**
+
+- Configuring keyArgs for pagination
+- Cache key generation
+- Handling dynamic arguments
+- Debugging cache behavior
+
+**📖 Learn more:** [Key Arguments Configuration](https://www.apollographql.com/docs/react/pagination/key-args)
+
+---
+
+### Local State Management
+
+**What it is:** Managing application state that doesn't come from the server using Apollo Client's local state capabilities.
+
+**Why it matters:** Provides a unified approach to handling both remote and local data, reducing the need for additional state management libraries.
+
+**Key topics covered:**
+
+- Reactive variables
+- Local-only fields
+- Client-side resolvers
+- State persistence strategies
+
+**📖 Learn more:** [Local State Management](https://www.apollographql.com/docs/react/local-state/local-state-management)
+
+---
+
+### Client-Side Field Policies
+
+**What it is:** Custom logic for reading, writing, and merging specific fields in Apollo Client's cache.
+
+**Why it matters:** Enables complex cache behaviors, computed fields, and custom data transformations at the field level.
+
+**Key topics covered:**
+
+- Read and merge functions
+- Field-level cache customization
+- Computed fields implementation
+- Performance optimization techniques
+
+**📖 Learn more:** [Managing State with Field Policies](https://www.apollographql.com/docs/react/local-state/managing-state-with-field-policies)
+
+---
+
+### Type Policies
+
+**What it is:** Configuration that defines how Apollo Client handles caching and normalization for specific GraphQL types.
+
+**Why it matters:** Controls cache behavior, enables custom key generation, and optimizes cache performance for your specific data model.
+
+**Key topics covered:**
+
+- Custom key fields configuration
+- Type-specific cache policies
+- Cache normalization strategies
+- Performance optimization
+
+**📖 Learn more:** [Type Policies Configuration](https://www.apollographql.com/docs/react/caching/cache-configuration#customizing-type-policies)
+
+---
+
+### Cache Management
+
+**What it is:** Direct interaction with Apollo Client's normalized cache for reading, writing, and updating data.
+
+**Why it matters:** Enables fine-grained control over cache behavior, manual cache updates, and complex state synchronization scenarios.
+
+**Key topics covered:**
+
+- Reading from and writing to cache
+- Cache eviction strategies
+- Manual cache updates
+- Cache debugging techniques
+
+**📖 Learn more:** [Cache Interaction](https://www.apollographql.com/docs/react/caching/cache-interaction)
+
+---
+
+### Schema-Driven Testing
+
+**What it is:** Testing approach that leverages your GraphQL schema to ensure type safety and consistency in tests.
+
+**Why it matters:** Provides confidence that your frontend code works correctly with your GraphQL API, catching type mismatches and schema changes early.
+
+**Key topics covered:**
+
+- MockedProvider setup
+- Schema-based mocking
+- Integration testing strategies
+- Type-safe test utilities
+
+**📖 Learn more:** [Schema-Driven Testing](https://www.apollographql.com/docs/react/development-testing/schema-driven-testing)
+
+---
+
+## Core Backend
+
+### Apollo Server
+
+**What it is:** A production-ready, spec-compliant GraphQL server that works with any GraphQL schema built with GraphQL.js.
+
+**Why it matters:** Provides the foundation for your GraphQL API, handling schema execution, middleware, and integration with various data sources.
+
+**Key topics covered:**
+
+- Server setup and configuration
+- Schema definition and resolvers
+- Middleware and plugins
+- Data source integration
+- Performance and security considerations
+
+**📖 Learn more:** [Apollo Server Getting Started](https://www.apollographql.com/docs/apollo-server/getting-started)
+
+---
+
+## Getting Started
+
+1. **Start with Core Concepts** - Understand OOP principles and dependency injection patterns
+2. **Set up Apollo Server** - Establish your GraphQL backend foundation
+3. **Configure Apollo Client** - Set up your frontend data layer
+4. **Implement Data Patterns** - Apply pagination, caching, and state management
+5. **Add Testing** - Implement schema-driven testing for reliability
+
+## Additional Resources
+
+- **Apollo Documentation:** [https://www.apollographql.com/docs/](https://www.apollographql.com/docs/)
+- **TypeScript Handbook:** [https://www.typescriptlang.org/docs/](https://www.typescriptlang.org/docs/)
+- **GraphQL Specification:** [https://spec.graphql.org/](https://spec.graphql.org/)
+
+---
+
+_This documentation is designed to be a living guide. Update it as new patterns and practices are adopted in the project._

package/lib/templates/content/docs/mailing/index.md

@@ -0,0 +1,14 @@
+---
+meta:
+    title: Mailling
+    description: Mailling
+date: '2023-06-02T00:00:00'
+updated: '2024-06-02T00:00:00'
+excerpt: Mailling...
+headers:
+    Cache-Control: no-cache
+---
+
+## Mailling
+
+**[Mailing Templates](/docs/mailing/mailing-template)**

package/lib/templates/content/docs/mailing/mailing-template.md

@@ -0,0 +1,148 @@
+---
+meta:
+    title: Mailing Template
+    description: Mailing Template
+date: '2023-06-02T00:00:00'
+updated: '2024-06-02T00:00:00'
+excerpt: Mailing Template...
+headers:
+    Cache-Control: no-cache
+---
+
+## Mailing Templates
+
+#### Create a Template
+
+Under your module's `src` folder, create a new folder named `migration` (if haven't already). Define your `ejs` mail
+template under this directory.
+
+##### Create neccessary types
+
+Create a unique template name.
+
+> packages-modules/account-api/server/src/graphql/schema/mail-services.graphql
+
+```typescript
+extend enum MailTemplateId {
+    """ Prefix with Db to make sure it look into the database """
+    DbTeamInivitationId
+}
+```
+
+and run `yarn generateGraphql` so it generates `types` in the core package.
+
+Make sure to build the core package where it get generated.
+
+#### Define a migration
+
+Define your migration file, import your newly defined template and define both `up` and `down` methods.
+
+> packages-modules/account-api/server/src/migrations/holiday-greetings-mail-template.ts
+
+```typescript
+import { IMailTemplateId } from '@adminide-stack/core';
+import { MailTemplateMigration } from '@container-stack/mailing-api-server';
+import { injectable } from 'inversify';
+import { config } from '../config';
+
+const template = require('./template-name.ejs'); // replace with actual template-name
+
+@injectable()
+export class HolidayGreetingsTemplateMigration extends MailTemplateMigration {
+    protected NAMESPACE = config.NAMESPACE;
+
+    protected VERSION = '20220502'; <-- CURRENT DATE IN FORMAT 'YYYYMMDD'. Any time change in template make sure to change this to redeploy
+
+    protected name = IMailTemplateId.HolidayGreetingsTemplateId;
+
+    protected templatePayload(): Record<string, unknown> {
+        return {
+            description: 'Holiday Greeting',
+            html: template.default,
+        };
+    }
+}
+```
+
+#### PS
+
+Make sure that you define unique `name` for your template
+
+#### Bind to Container
+
+Bind your newly added migration with container so that it gets migrated when server stars
+
+> packages-modules/account-api/server/src/containers/module.ts
+
+```typescript
+
+    bind('MongodbMigration')
+        .to(<Your-Template-Class>)
+        .whenTargetNamed(<Your-Template-Class>.name);
+```
+
+#### Sending Email
+
+In any service where you want to call to `sendEmail` for example
+
+> packages-modules/billing-api/server/src/plugins/stripe-moleculer-service.ts
+
+```typescript
+// These import can be from '@container-stack/mailing-api' as well
+import { ISendMail_Input, IMoleculerServiceName, IMailServiceAction } from '@adminide-stack/core';
+
+class ExampleService {
+    @inject(CommonType.MOLECULER_BROKER)
+    protected broker: ServiceBroker;
+    constructor() {}
+
+    private async anyOtherFunctionCallingSendEmail(request, transport) {
+        try {
+            const emailResponse = await this.broker.call(
+                `${IMoleculerServiceName.MailService}.${IMailServiceAction.SendEmail}`,
+                {
+                    request: {
+                        from: config.MAIL_SEND_DEFAULT_EMAIL,
+                        to,
+                        topic: '',
+                        templateId: IMailTemplateId.BillingNotificationId,
+                        namespace: config.NAMESPACE,
+                        variables: {
+                            // add any variables that you need to pass to template.
+                            text: variables.subject,
+                            messageHtml: '',
+                            message: '',
+                            ...variables,
+                        },
+                    } as ISendMail_Input,
+                    transport,
+                },
+            );
+        } catch (err) {
+            this.logger.error(err);
+        }
+    }
+}
+```
+
+Add required email environment variables in `config`
+
+```typescript
+export const config = envalid.cleanEnv<IConfig>(process.env, {
+    ...
+    MAIL_SEND_DEFAULT_EMAIL: str(),
+    EMAIL_USER: str(),
+    ...
+});
+```
+
+##### We support following operations on `mailer-service`
+
+1. Send
+2. SendBulkEmail
+3. Query
+4. Report
+5. CreateTemplate
+6. SaveTemplate
+7. DropTemplate
+8. List