# 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