Conversation
Reviewer's GuideAdds a multi-step Mirakl import flow that supports uploading product export files and a dedicated Mirakl import detail page, wires them into routing and listings, and adjusts GraphQL schema usage for Mirakl-related entities. Sequence diagram for the new Mirakl product import creation flow with file uploadssequenceDiagram
actor User
participant MiraklImporter as MiraklImporterVue
participant Router
participant Apollo as ApolloClient
participant GQL as GraphQLAPI
participant ImportProcess as MiraklImportProcess
participant ExportFile as MiraklImportExportFile
User->>MiraklImporter: Open Mirakl import wizard
MiraklImporter->>Apollo: getMiraklChannelQuery(integrationId)
Apollo->>GQL: getMiraklChannelQuery
GQL-->>Apollo: miraklChannel(salesChannel.id, hasFinishedSchema)
Apollo-->>MiraklImporter: miraklChannel data
User->>MiraklImporter: Select importType products
User->>MiraklImporter: Configure importSettings
User->>MiraklImporter: Upload .xlsx export files
MiraklImporter->>MiraklImporter: onUploaded(files) filter and store exportFiles
User->>MiraklImporter: Click Finish
MiraklImporter->>MiraklImporter: handleFinish()
MiraklImporter->>MiraklImporter: validate salesChannelId and exportFiles
MiraklImporter->>Apollo: createMiraklImportProcessMutation(data)
Apollo->>GQL: createMiraklImportProcess
GQL-->>Apollo: createMiraklImportProcess(id)
Apollo-->>MiraklImporter: importProcessId
MiraklImporter->>ImportProcess: create pending process (logical)
loop for each file in exportFiles
MiraklImporter->>Apollo: createMiraklImportExportFileMutation(data)
Apollo->>GQL: createMiraklImportExportFile
GQL-->>Apollo: created exportFile(id, fileUrl)
Apollo-->>MiraklImporter: exportFile result
MiraklImporter->>ExportFile: associate file with process (logical)
end
MiraklImporter->>User: Toast.success(integrations.imports.create.success)
MiraklImporter->>Router: push(name integrations.integrations.show, query tab imports)
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
- In
MiraklImportShowController.vue,integrationIdis taken frommiraklImportProcess.salesChannel.idand then used to build theintegrations.integrations.showbreadcrumb link; if that route expects the sales channel’sproxyId(as in other components you updated), this will navigate with the wrong identifier and should be aligned. fetchImportinMiraklImportShowController.vueswallows query errors and only flipsloading; consider at least logging or surfacing a toast/empty state when the query fails so the user isn’t left with an indefinite loader or a blank card.result,miraklImport, andmiraklExportFilesinMiraklImportShowController.vueare all typed asany/implicitany; adding a small interface for the GraphQL response and using proper generics onapolloClient.querywould make the component safer and easier to maintain.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In `MiraklImportShowController.vue`, `integrationId` is taken from `miraklImportProcess.salesChannel.id` and then used to build the `integrations.integrations.show` breadcrumb link; if that route expects the sales channel’s `proxyId` (as in other components you updated), this will navigate with the wrong identifier and should be aligned.
- `fetchImport` in `MiraklImportShowController.vue` swallows query errors and only flips `loading`; consider at least logging or surfacing a toast/empty state when the query fails so the user isn’t left with an indefinite loader or a blank card.
- `result`, `miraklImport`, and `miraklExportFiles` in `MiraklImportShowController.vue` are all typed as `any`/implicit `any`; adding a small interface for the GraphQL response and using proper generics on `apolloClient.query` would make the component safer and easier to maintain.
## Individual Comments
### Comment 1
<location path="src/core/integrations/integrations/integrations-show/containers/imports/containers/import-show/MiraklImportShowController.vue" line_range="61-70" />
<code_context>
+ void fetchImport();
+});
+
+const formatDate = (dateString: string) => {
+ const date = new Date(dateString);
+ return new Intl.DateTimeFormat('en-GB', {
+ year: 'numeric',
+ month: '2-digit',
+ day: '2-digit',
+ hour: '2-digit',
+ minute: '2-digit',
+ hour12: false,
+ }).format(date);
+};
+</script>
</code_context>
<issue_to_address>
**suggestion:** Use the active i18n locale for date formatting instead of hardcoding 'en-GB'
`formatDate` currently uses `new Intl.DateTimeFormat('en-GB', ...)`, which bypasses the user’s chosen locale and can diverge from the rest of the UI. Since `useI18n` is available, please build the formatter from `t`/`d` or `i18n.locale.value` (or a shared date-format utility) so dates honor the active locale.
Suggested implementation:
```
const formatDate = (dateString: string) => {
const date = new Date(dateString);
return new Intl.DateTimeFormat(locale.value, {
year: 'numeric',
month: '2-digit',
day: '2-digit',
hour: '2-digit',
minute: '2-digit',
hour12: false,
}).format(date);
};
```
To make this work you also need to:
1. Ensure `useI18n` is imported in the `<script setup>` of this file (if not already): `import { useI18n } from 'vue-i18n';`
2. Destructure `locale` from `useI18n` at the top level of the script (next to where `t` is likely used), e.g.:
`const { t, locale } = useI18n();`
If the project uses a shared date-formatting utility based on i18n, consider replacing `formatDate` entirely with that utility instead of using `Intl.DateTimeFormat` directly.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| const formatDate = (dateString: string) => { | ||
| const date = new Date(dateString); | ||
| return new Intl.DateTimeFormat('en-GB', { | ||
| year: 'numeric', | ||
| month: '2-digit', | ||
| day: '2-digit', | ||
| hour: '2-digit', | ||
| minute: '2-digit', | ||
| hour12: false, | ||
| }).format(date); |
There was a problem hiding this comment.
suggestion: Use the active i18n locale for date formatting instead of hardcoding 'en-GB'
formatDate currently uses new Intl.DateTimeFormat('en-GB', ...), which bypasses the user’s chosen locale and can diverge from the rest of the UI. Since useI18n is available, please build the formatter from t/d or i18n.locale.value (or a shared date-format utility) so dates honor the active locale.
Suggested implementation:
const formatDate = (dateString: string) => {
const date = new Date(dateString);
return new Intl.DateTimeFormat(locale.value, {
year: 'numeric',
month: '2-digit',
day: '2-digit',
hour: '2-digit',
minute: '2-digit',
hour12: false,
}).format(date);
};
To make this work you also need to:
- Ensure
useI18nis imported in the<script setup>of this file (if not already):import { useI18n } from 'vue-i18n'; - Destructure
localefromuseI18nat the top level of the script (next to wheretis likely used), e.g.:
const { t, locale } = useI18n();
If the project uses a shared date-formatting utility based on i18n, consider replacingformatDateentirely with that utility instead of usingIntl.DateTimeFormatdirectly.
Summary by Sourcery
Add support for Mirakl product imports with file upload and dedicated import detail view.
New Features:
Bug Fixes:
Enhancements: