---
# System prepended metadata

title: Todo

---

# 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
