Frontend naming conventions and UI guide

[ManojNathIC]

No description provided.

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• Documentation
  • Added a frontend style and architecture guide for the Analytics Dashboard, providing comprehensive naming and component conventions, recommended directory/layout patterns, guidance for chart and reusable component design, and general development principles to promote modularity, consistency, and maintainability across the project.

Walkthrough

A new frontend documentation file adds mandatory naming conventions and architectural rules for the Analytics Dashboard, covering component/file naming, directory conventions, export patterns, component architecture, and development guidance.

Changes

Cohort / File(s)	Summary
Frontend Documentation 4-frontend/ui-naming-conventions-coding-guide.md	Added a coding guide specifying naming conventions (PascalCase for React components, camelCase for utilities/types, kebab-case for directories), enforcing named exports, props interfaces named [ComponentName]Props, component architecture (modular dirs, chart wrappers, dataKey/nameKey mapping), and development standards (no hardcoding, max ~250-line components).

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	No description was provided by the author, making it impossible to evaluate whether it relates to the changeset.	Add a description explaining the purpose and scope of the naming conventions guide for better context.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: addition of a frontend naming conventions and UI guide documentation file.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

No actionable comments were generated in the recent review. 🎉

🧹 Recent nitpick comments

4-frontend/ui-naming-conventions-coding-guide.md (2)

17-19: Clarify the incorrect example.

Line 19 shows export default Header; but doesn't clearly indicate this is the incorrect pattern to avoid. Consider adding a visual indicator or comment to distinguish correct from incorrect examples.

📝 Proposed clarification

 ### Component Exports
 - **Strictly Named Exports**: Do NOT use `default export`.
-  - `export const Header = () => { ... }`
-  - `export default Header;`
+  - ✅ Correct: `export const Header = () => { ... }`
+  - ❌ Incorrect: `export default Header;`

---

31-34: Document appears incomplete.

The file ends abruptly at line 34 within the "Charting Patterns" subsection. The past review comments reference a "Development Principles" section and additional content that would have provided important guidance on hardcoding, section numbering, and other development practices. Consider completing this section or adding the missing sections if this is intended to be a comprehensive guide.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In `@4-frontend/ui-naming-conventions-coding-guide.md`:
- Around line 36-38: Update the "No Hardcoding" guidance under the "Development
Principles" section to clarify that .env is only for environment-specific
configuration and secrets, and that UI/static strings should be moved to a
config/constants module or an i18n/localization layer; replace the phrase ".env
for static strings" with explicit guidance to keep only env-specific values in
.env and to store user-facing/static text in config/constants or i18n files
(refer to the "No Hardcoding" bullet and the surrounding "Development
Principles" heading to locate the text to update).
- Around line 36-40: The document jumps from section 2 to "## 5. Development
Principles", which is confusing; update the heading "## 5. Development
Principles" to the correct sequential number (e.g., "## 3. Development
Principles") or insert the missing sections with appropriate headings and
placeholder content so numbering flows correctly; specifically edit the heading
text "## 5. Development Principles" (and any internal references to that
heading) to restore sequential numbering across the file.

🧹 Nitpick comments (1)

4-frontend/ui-naming-conventions-coding-guide.md (1)

16-20: Clarify the “no default export” example.

Right now the export default Header; line appears as a valid example immediately after “Do NOT use default export,” which can be misread. Either remove it or explicitly label it as a “❌ Incorrect” example.

Proposed edit

-  - `export default Header;`
+  - ❌ `export default Header;`

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

“.env for static strings” is misleading.

.env should be for environment‑specific values/secrets, not general UI strings. Recommend moving static strings to config/constants or i18n, and keep only env‑specific values in .env.

Proposed edit

-- **No Hardcoding**: Strictly move all configuration values, API endpoints, and static strings to `.env` or configuration modules.
+- **No Hardcoding**: Move environment-specific values (API endpoints, secrets) to `.env`, and place static strings in config/constants or i18n modules.

🤖 Prompt for AI Agents

In `@4-frontend/ui-naming-conventions-coding-guide.md` around lines 36 - 38,
Update the "No Hardcoding" guidance under the "Development Principles" section
to clarify that .env is only for environment-specific configuration and secrets,
and that UI/static strings should be moved to a config/constants module or an
i18n/localization layer; replace the phrase ".env for static strings" with
explicit guidance to keep only env-specific values in .env and to store
user-facing/static text in config/constants or i18n files (refer to the "No
Hardcoding" bullet and the surrounding "Development Principles" heading to
locate the text to update).