Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve xlsx import #1271

Open
wants to merge 9 commits into
base: master
Choose a base branch
from
Open

Improve xlsx import #1271

wants to merge 9 commits into from

Conversation

alex-Arc
Copy link
Collaborator

@alex-Arc alex-Arc commented Oct 17, 2024

  • switch from node-xlsx to xlsx
  • evaluate excel formulars functions
  • allow space and upper case in custom import

@cpvalente
Copy link
Owner

@coderabbitai full review

Copy link
Contributor

coderabbitai bot commented Oct 20, 2024

✅ Actions performed

Full review triggered.

Copy link
Contributor

coderabbitai bot commented Oct 20, 2024

Walkthrough

This pull request introduces several changes across multiple components and services, primarily focusing on enhancing the handling of custom fields and improving input validation. The ImportMapForm component's validation logic is updated to allow spaces in custom field names. The PreviewRundown component's variable handling is refined, while the excel.service.ts file shifts to a new library for Excel file processing. Additionally, the SheetService and parser modules are modified to incorporate custom fields into their data handling processes, ensuring more flexible and robust functionality.

Changes

File Change Summary
apps/client/src/features/app-settings/panel/sources-panel/import-map/ImportMapForm.tsx Updated import statement to include isAlphanumericWithSpace. Changed validation for ontimeName input field to allow spaces in addition to alphanumeric characters.
apps/client/src/features/app-settings/panel/sources-panel/preview/PreviewRundown.tsx Renamed variable fieldHeaders to fieldKeys and introduced fieldLabels for rendering table headers. Updated rendering logic to utilize fieldLabels instead of fieldHeaders.
apps/server/src/api-data/excel/excel.service.ts Updated import from node-xlsx to xlsx. Changed excelData type from an array of objects to WorkBook. Modified saveExcelFile to use xlsx.readFile and updated data access methods accordingly.
apps/server/src/services/sheet-service/SheetService.ts Added import for getCustomFields. Updated upload and download methods to include custom fields in parseExcel function calls.
apps/server/src/utils/__tests__/parser.test.ts Imported CustomFields type. Updated getCustomFieldData and parseExcel function signatures to accept existing custom fields. Expanded test cases to verify handling of custom fields and color information.
apps/server/src/utils/parser.ts Enhanced getCustomFieldData and parseExcel functions to utilize existingCustomFields. Updated logic for color property assignment in getCustomFieldData.

Possibly related PRs


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 5

🧹 Outside diff range and nitpick comments (5)
apps/client/src/features/app-settings/panel/sources-panel/preview/PreviewRundown.tsx (1)

Line range hint 106-111: Suggestion for custom field value rendering

The use of fieldKeys for rendering custom field values is correct and consistent with earlier changes. The existence check before accessing event.custom[field] is also a good practice. However, consider the following improvements:

  1. Make the empty string fallback more explicit.
  2. Use optional chaining and nullish coalescing for a more concise implementation.

Here's a suggested refactor:

 fieldKeys.map((field) => {
-  let value = '';
-  if (field in event.custom) {
-    value = event.custom[field];
-  }
-  return <td key={field}>{value}</td>;
+  const value = event.custom?.[field] ?? '';
+  return <td key={field}>{value}</td>;
 })}

This change maintains the same functionality while making the code more concise and explicit about the fallback value.

apps/client/src/features/app-settings/panel/sources-panel/import-map/ImportMapForm.tsx (1)

192-195: LGTM: Updated validation to allow spaces in custom field names

The validation logic has been successfully updated to allow spaces in custom field names, which aligns with the PR objectives. The implementation using isAlphanumericWithSpace is correct and the error message is clear.

Consider adding a check for empty strings to improve user experience:

 validate: (value) => {
+  if (!value.trim()) return 'Field name cannot be empty';
   if (!isAlphanumericWithSpace(value))
     return 'Only alphanumeric characters and space are allowed';
   return true;
 },

This addition will prevent users from submitting empty field names while still allowing spaces.

apps/server/src/utils/parser.ts (2)

58-76: Improved custom field handling with color preservation.

The changes to getCustomFieldData function enhance the handling of custom fields by preserving existing color information. This aligns well with the PR objective of improving custom field management.

Consider using optional chaining for a more concise color assignment:

-const colour = ontimeKey in existingCustomFields ? existingCustomFields[ontimeKey].colour : '';
+const colour = existingCustomFields[ontimeKey]?.colour ?? '';

This change would slightly improve readability and reduce the need for an explicit check.


Line range hint 87-101: Enhanced Excel parsing with existing custom fields support.

The changes to parseExcel function improve the handling of custom fields during Excel import by incorporating existing custom field data. This enhancement aligns well with the PR objective of improving Excel import functionality.

Consider adding a type annotation for the existingCustomFields parameter to improve code readability and maintainability:

export const parseExcel = (
  excelData: unknown[][],
- existingCustomFields: CustomFields,
+ existingCustomFields: CustomFields,
  options?: Partial<ImportMap>,
): ExcelData => {
  // ... (rest of the function)

This change would make the function signature more explicit about the expected type of existingCustomFields.

apps/server/src/utils/__tests__/parser.test.ts (1)

978-978: Inconsistent casing in custom field keys.

The key 'User1' uses mixed casing, while other keys like 'user0' are in lowercase. This might lead to issues due to case sensitivity.

Consider standardizing the casing of custom field keys to avoid potential inconsistencies or bugs related to case-sensitive operations.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between c587045 and 4856fb1.

⛔ Files ignored due to path filters (2)
  • apps/server/package.json is excluded by none and included by none
  • pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml and included by none
📒 Files selected for processing (6)
  • apps/client/src/features/app-settings/panel/sources-panel/import-map/ImportMapForm.tsx (2 hunks)
  • apps/client/src/features/app-settings/panel/sources-panel/preview/PreviewRundown.tsx (3 hunks)
  • apps/server/src/api-data/excel/excel.service.ts (2 hunks)
  • apps/server/src/services/sheet-service/SheetService.ts (3 hunks)
  • apps/server/src/utils/tests/parser.test.ts (14 hunks)
  • apps/server/src/utils/parser.ts (4 hunks)
🧰 Additional context used
🔇 Additional comments (21)
apps/client/src/features/app-settings/panel/sources-panel/preview/PreviewRundown.tsx (2)

27-28: Improved handling of custom fields

The introduction of fieldKeys and fieldLabels is a good improvement. This separation of concerns allows for more flexible usage of custom field data throughout the component.


48-49: Correct usage of fieldLabels for table headers

The update to use fieldLabels for rendering table headers is correct and consistent with the earlier changes. This ensures that user-friendly labels are displayed in the table.

apps/client/src/features/app-settings/panel/sources-panel/import-map/ImportMapForm.tsx (2)

6-6: LGTM: Updated import to allow spaces in custom fields

The import of isAlphanumericWithSpace from 'ontime-utils' aligns with the PR objective of allowing spaces in custom imports. This change sets the foundation for the updated validation logic.


Line range hint 1-238: Overall assessment: Changes successfully implement PR objectives

The modifications to ImportMapForm.tsx effectively implement the PR objective of allowing spaces in custom imports. The changes are focused and minimal, which reduces the risk of unintended side effects. The updated import and validation logic work together to provide a more flexible user experience when defining custom field names.

To ensure that these changes don't affect other parts of the codebase, please run the following verification script:

This will help identify any other locations where isAlphanumeric is used, which might need to be updated to isAlphanumericWithSpace for consistency.

✅ Verification successful

To address the issue with the previous shell script, please run the following corrected verification script:


To resolve the issue with the previous shell script, please run the following corrected verification script:


Overall assessment: Changes successfully implement PR objectives

The modifications to ImportMapForm.tsx effectively implement the PR objective of allowing spaces in custom imports. The changes are focused and minimal, which reduces the risk of unintended side effects. The updated import and validation logic are consistent with existing usages of isAlphanumericWithSpace across the codebase, ensuring a seamless and flexible user experience when defining custom field names.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for any other usages of 'isAlphanumeric' that might need updating

# Test: Search for other usages of 'isAlphanumeric'
rg "isAlphanumeric" --type ts --type tsx

Length of output: 68


Script:

# 
#!/bin/bash
# Description: Check for any other usages of 'isAlphanumeric' that might need updating

# Corrected Test: Search for other usages of 'isAlphanumeric' in .ts and .tsx files
rg "isAlphanumericWithSpace" --type ts --type tsx

Length of output: 77


Script:

# 
#!/bin/bash
# Description: Check for any other usages of 'isAlphanumericWithSpace' that might need updating

# Corrected Test: Search for other usages of 'isAlphanumericWithSpace' in .ts and .tsx files using glob patterns
rg "isAlphanumericWithSpace" -g "*.ts" -g "*.tsx"

Length of output: 1613

apps/server/src/services/sheet-service/SheetService.ts (4)

21-21: LGTM: New import for custom fields handling.

The addition of getCustomFields import aligns with the PR objective of enhancing custom field support. This function will be used to retrieve custom fields for Excel parsing, improving the flexibility of the import process.


292-292: LGTM: Improved Excel parsing with custom fields support.

The modification to include getCustomFields() in the parseExcel function call enhances the upload process by incorporating custom fields. This change ensures that the Excel parsing takes into account user-defined fields, aligning with the PR's goal of improving custom import handling.


369-369: LGTM: Consistent custom fields handling in download operation.

The addition of getCustomFields() to the parseExcel function call in the download process mirrors the change made in the upload function. This ensures consistent handling of custom fields across both operations, maintaining data integrity and improving the overall robustness of the Excel import/export functionality.


21-21: Summary: Improved custom fields handling in Sheet Service.

The changes made to this file consistently enhance the handling of custom fields in both upload and download operations. The addition of getCustomFields() to the Excel parsing process ensures that user-defined fields are properly incorporated, aligning well with the PR's objective of improving xlsx import functionality. These modifications contribute to a more flexible and robust integration with Google Sheets.

Also applies to: 292-292, 369-369

apps/server/src/utils/parser.ts (1)

Line range hint 1-451: Overall improvements in custom field handling and Excel import.

The changes in this file successfully enhance the custom field handling and Excel import functionality. The modifications to getCustomFieldData and parseExcel functions are well-aligned with the PR objectives and improve the overall robustness of the codebase.

The changes are focused and effective, maintaining the existing structure while adding necessary functionality. Good job on improving the Excel import process and custom field management!

apps/server/src/utils/__tests__/parser.test.ts (12)

5-5: Importing CustomFields is appropriate.

The CustomFields type is now imported from 'ontime-types', which is necessary for the type definitions used in the test cases below.


Line range hint 792-817: Test case correctly verifies getCustomFieldData output.

The test ensures that getCustomFieldData generates the correct customFields and customFieldImportKeys when provided with an importMap and an empty existing custom fields object.


818-865: Verify consistency of custom field labels.

In the existing customFields, the label for 'lighting' is 'lx', but after processing, the label becomes 'lighting'. This changes the label from 'lx' to 'lighting', which may not be intended.

Please confirm if the transformation of the label from 'lx' to 'lighting' in the result is expected. If the original labels should be preserved, consider adjusting the implementation to maintain consistency.


1011-1031: Test accurately checks retention of color information in custom fields.

The test verifies that when parsing Excel data, the existing custom fields' color information is retained. The assertions confirm that colors for 'user0', 'User1', and 'user2' are correctly preserved.


1188-1188: Ensure parseExcel handles absence of custom fields gracefully.

The test checks parsing Excel data without custom fields specified. Confirm that the implementation can handle cases where custom fields are not provided without errors.

Please verify that the parseExcel function appropriately manages scenarios with no custom fields to prevent unexpected behavior.


1294-1294: Verify event type handling in parseExcel.

The test ensures that unknown event types are correctly ignored during parsing. This is important for robustness, but make sure that valid events are not mistakenly skipped.

Consider adding additional validation or logging to capture any events that are ignored to aid in debugging if valid events are missed.


1387-1387: Correct handling of block events in Excel import.

The test confirms that block events are imported correctly from Excel data. This maintains the integrity of the event sequence in the rundown.


1457-1457: Ensure default timer type is set when missing or whitespace.

The test verifies that when the 'timer type' column is empty or contains only whitespace, events default to TimerType.CountDown.


1575-1575: Accurate parsing of timer types with leading/trailing whitespace.

The test checks that timer types with leading or trailing whitespace are correctly interpreted, such as ' count-up '. This ensures that user input variations do not cause parsing errors.


1616-1616: Time conversions are correctly handled for AM/PM formats.

The test confirms that times specified in AM/PM formats are accurately converted to 24-hour timestamps. This is essential for correct event scheduling.


1653-1653: Handle leading and trailing whitespace in headers and data.

The test ensures that both import map keys and Excel data with leading or trailing whitespace are parsed correctly. This improves the robustness of the import functionality.


1705-1705: Verify link start logic in event parsing.

The test checks the correct application of the linkStart property across various events, including those following blocks. It's important to ensure that linked events have accurate start times.

Please ensure that events with linkStart set to true correctly adjust their timeStart based on the preceding event's timeEnd, even when blocks are present.

Copy link
Owner

@cpvalente cpvalente left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you alex, good work

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants