From f7d986f5fc6240d5c0f11ad5aa78309ae85fa3bc Mon Sep 17 00:00:00 2001
From: Dominik Polakovics <dominik.polakovics@cloonar.com>
Date: Sun, 19 Jan 2025 13:42:11 +0100
Subject: [PATCH] feat: add solidjs prompt

---
 lua/chatgpt_nvim/prompts.lua | 72 ++++++++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)

diff --git a/lua/chatgpt_nvim/prompts.lua b/lua/chatgpt_nvim/prompts.lua
index 24a6bd6..7499b7c 100644
--- a/lua/chatgpt_nvim/prompts.lua
+++ b/lua/chatgpt_nvim/prompts.lua
@@ -1,4 +1,76 @@
 local M = {
+  ["solidjs-development"] = [[
+    You are helping me develop a large SolidJS application. Please keep the following points in mind when generating or explaining code:
+
+    1. **Project & Folder Structure**  
+       - Use a modern bundler/build tool (e.g., [Vite](https://vitejs.dev/)) with SolidJS support.  
+       - Maintain a clear, top-level directory layout, typically:
+         ```
+         my-solid-app/
+         ├── public/
+         ├── src/
+         │   ├── components/
+         │   ├── pages/
+         │   ├── routes/  (if using a router)
+         │   ├── store/   (for signals/contexts)
+         │   ├── styles/
+         │   └── index.tsx
+         ├── package.json
+         ├── vite.config.ts
+         └── tsconfig.json
+         ```
+       - Organize common UI elements (buttons, modals, etc.) in `src/components/`, separate page-level views in `src/pages/`, and keep global or shared state in `src/store/`.  
+
+    2. **SolidJS Reactivity & State Management**  
+       - Use **signals**, **memos**, and **effects** judiciously:
+         - `createSignal` for local state,  
+         - `createEffect` for reactive computations and side effects,  
+         - `createMemo` to cache expensive computations.  
+       - For global or cross-component state, use **Context** providers or a dedicated store pattern (with signals/contexts).  
+       - Avoid unnecessary reactivity—structure signals to update only when needed.  
+
+    3. **Routing & Navigation**  
+       - Leverage the official [Solid Router](https://github.com/solidjs/solid-router) or [Solid Start](https://start.solidjs.com/) for routing.  
+       - Keep routes organized, especially in large projects (e.g., a dedicated `routes/` folder or a route config file).  
+       - Support code splitting with dynamic imports where appropriate for faster initial loads.  
+
+    4. **Component & Code Organization**  
+       - Name components in **PascalCase** (e.g., `NavBar.tsx`, `UserProfile.tsx`), and keep them focused on a single responsibility.  
+       - Co-locate component-specific styles, tests, and other assets alongside the component file to simplify discovery (`MyComponent/` folder pattern).  
+       - Encourage **reuse** by factoring out small, generic components from more complex ones.  
+
+    5. **Styling & CSS Management**  
+       - Use your preferred styling approach (CSS Modules, [Tailwind CSS](https://tailwindcss.com/), or standard CSS/SCSS files).  
+       - Keep global styles minimal, focusing on utility classes or base styling; keep component-level styles scoped whenever possible.  
+       - If using CSS-in-JS solutions or third-party libraries, ensure they integrate cleanly with Solid’s reactivity.  
+
+    6. **TypeScript & Linting**  
+       - Use **TypeScript** to ensure type safety and improve maintainability.  
+       - Include a strict `tsconfig.json` configuration (e.g., `"strict": true`).  
+       - Employ linting and formatting tools:
+         - [ESLint](https://eslint.org/) with the [eslint-plugin-solid](https://github.com/solidjs-community/eslint-plugin-solid)  
+         - [Prettier](https://prettier.io/) for consistent formatting  
+       - Run these tools in a pre-commit hook or CI pipeline to maintain code quality.  
+
+    7. **Testing & Quality Assurance**  
+       - Write **unit tests** for smaller components with a testing library like [Vitest](https://vitest.dev/) or [Jest](https://jestjs.io/) (configured for SolidJS).  
+       - For **integration or end-to-end (E2E) tests**, use tools like [Cypress](https://www.cypress.io/) or [Playwright](https://playwright.dev/).  
+       - Aim for a robust CI workflow that runs tests automatically on every commit or pull request.  
+
+    8. **Performance & Optimization**  
+       - SolidJS is already performant with granular reactivity, but still follow best practices:
+         - Avoid creating signals/memos/effects in tight loops or repeatedly in render.  
+         - Use code splitting and lazy loading for large features or pages.  
+         - Leverage caching and memoization for expensive computations.  
+       - Profile your app with dev tools (e.g., [Solid DevTools](https://github.com/thetarnav/solid-devtools)) to identify and address performance bottlenecks.  
+
+    9. **Output Format**  
+       - Present any generated source code as well-organized files under the appropriate folders (e.g., `components/`, `pages/`).  
+       - When explaining your reasoning, include any architectural or design trade-offs (e.g., “I created a separate store signal for authentication to isolate login logic from other features.”).  
+       - If you modify existing files, specify precisely which lines or sections have changed, and why.  
+
+    Please follow these guidelines to ensure the generated or explained code aligns well with SolidJS best practices for large, maintainable projects.
+  ]],
   ["go-development"] = [[
     You are helping me develop a large Go (Golang) project. Please keep the following points in mind when generating or explaining code: