Basic Structure
The *Widget.vue file is the bridge between the plugin and racletteJS core.
This file is special – it's where all the core-tied behavior lives. Everything else? Totally up to you!
What This Means in Practice
exampleCreator__examplePlugin/
├── raclette.plugin.ts # Main plugin configuration
├── frontend/ # Frontend-side code (if frontendDir specified)
│ ├── [...] # See plugin metadata for more
│ └── widgets/ # Plugin widgets
│ ├── Example/ # Your custom Widget folder name
│ │ ├── ExampleWidget.vue # The widget File. Needs to follow this structure "[CustomName]Widget.vue"
│ │ ├── setup.ts # Contains details and config for the widget
│ │ └── [...]
│ └── [...]
└── backend/ # Server-side code (if backendDir specified)
├── index.ts # Server entry point
├── example.model.ts # The model for your dataType. Currently mongoose
├── example.schema.ts # The schema for your dataType. Fastify schema, validations etc
├── example.service.ts # The services for your dataType ie the actuall backend business logic
├── routes/ # API routes
└── helpers/ # Business logic helpers and utilsDetails of raclette.plugin.ts
Your *Widget.vue should:
- Handle all communication with the racletteJS core using the provided
pluginAPI - Pass data down to your child components via props or models
- Keep your business logic separate from the core business logic (makes life easier later!)
- Handle all orchestration of all your widget's components, such as custom modals or inner widget grid logic
- Have all props defined you want to configure in the workbench or pass via the router
Your child components can:
- Be organized any way you like
- Use any naming conventions you prefer
- Have whatever structure makes sense for your use case
All vue components should:
- Provide at least the prop
widgetId: { type: String, required: true }- This prop will be used to identify the widget state in the store
- If not provided nothing will break, but $store.getWidgetState() will return nothing if no widgetId is provided as prop