# Todo ## Auto import - [ ] configurable import structure - [ ] components - [ ] spec files - [ ] include locations where files should be created (like sample data and spec files) ## Spec File Builder - [ ] Saveable when using electron - [ ] spec files can be required - [ ] Can we go in reverse? Can we notice props on a component, and suggest they're added to the spec file? ## Creating Files - [ ] think through the architecture - [ ] electron api - [ ] creating a file - [ ] listing files (QTree) - [ ] enforcing only certain create operations ## Generators ### On dedicated "generators" page - [ ] Think through the api - [ ] allowing future generators to be plugged in - [ ] choose where generators are shown... if possible (e.g. create button next to left menu) ### On a component page - [ ] adding generators to a components page - [ ] generators will recieve component details - [ ] somehow, a "checkbox" generator? Something that can check if true or false (like if file exists, but not limited to) - [ ] allow commands to accept params that are scaffolded with schema generators also get a "README.md" that we can use for markdown and videos ## Composables How do we group them? maybe - base - model - service (maybe service isn't needed if `model` becomes `type`) ## Styling How do we think about styling? ## ORM? Creating models? ## Show component parents Can we create a feature that shows all the parents of a component? Maybe we ocassionally run a job that checks all vue files for where a component is used? ## Searching Building robust searching capabilities ## i18n Initial thought, is this should follow the same structure as everything else (`base components`, `modules`) Is there a non global way to handle i18n? ## Component Global Config Note, this concept probaby shouldn't leak into composables as it couples them to global config. not good! You could have a file like this`src/modules/Category/components/CategoryChip/CategoryChipConfig.ts` That is then pointed to in a global config file: ```ts import { CategoryChipConfig, CategoryChipConfigBase } from 'modules/Category/components/CategoryChip/CategoryChipConfig.ts' interface AppConfig { components: { CategoryChip: CategoryChipConfig } } const appConfig: AppConfig = { components: { CategoryChip: CategoryChipConfigBase } } ``` ## Nested Modules Nested modules **will not be possible** at a file level however... Devs will be able to create nesting in the UI, by adding configuration that looks something like this: ```js Farm: { } Collection: { within: 'farm' }, SowingCollection: { within: 'Collection' } ``` now the UI menu will look like this farm Collection Sowing Collection ## Documentation Page A page just for docs, with md files, and spec files. ## Pluggability - [ ] tools can be added for - [ ] dashboard - [ ] segment - [ ] module - [ ] group - [ ] tools have a way to save typed data `config/tools/group` ```ts export default { componentGrid: { platforms: ['electron', 'browser'], // 'main.preview' or 'main.toolset' defaultWindow: 'main.preview', label: 'Component Grid', groupKinds: ['component'] // could also be 'composable' } } ``` `getGroupPlugins()` ## Plugging into the props editor (adding/replacing inputs) maybe the components for the props editor uses provide/inject? We could merge the base editors input components with those provided by the user. ## Playgrounds