Convert remaining JS/JSX files to TypeScript#1316
Conversation
Convert all remaining .js and .jsx files to .ts/.tsx: - utils/posts.jsx -> .ts - utils/user_agent.jsx -> .ts - components/setting.jsx -> .tsx - components/setup_ui/setup_ui.jsx -> .tsx - components/setup_ui/index.js -> .ts - components/form_button.jsx -> .tsx - components/input.jsx -> .tsx - components/jira_issue_selector/jira_issue_selector.jsx -> .tsx - components/jira_issue_selector/index.js -> .ts - components/modals/full_screen_modal/full_screen_modal.jsx -> .tsx - components/jira_field.jsx -> .tsx Replaced PropTypes with proper TypeScript interfaces/types. Updated function signatures with typed parameters.
|
Warning Review limit reached
Next review available in: 5 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository UI (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughMultiple React components ( ChangesPropTypes → TypeScript Migration
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@webapp/src/components/input.tsx`:
- Around line 61-66: The handleChange method uses parseInt which truncates
decimal values, breaking float input fields. Replace parseInt with parseFloat to
preserve decimal values while still supporting integer types. Additionally,
there is a validation check (likely around line 73) that treats the numeric
value 0 as invalid due to falsy evaluation. Update this validation to explicitly
check for null or undefined instead of relying on truthiness checks, ensuring
that a zero value is properly accepted for required numeric fields.
In `@webapp/src/components/jira_field.tsx`:
- Around line 55-60: The Props type definition in the JiraField component
declares stricter types than what the caller in jira_fields.tsx actually
provides. Update the Props type definition: change the projectKey property from
string to string | undefined to match the caller's usage, and change the
issueMetadata property from Record<string, any> to IssueMetadata | null to align
with what the caller actually passes to the JiraField component.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: 2c43154c-e1a3-4e18-b8c5-68f1035316cb
📒 Files selected for processing (11)
webapp/src/components/form_button.tsxwebapp/src/components/input.tsxwebapp/src/components/jira_field.tsxwebapp/src/components/jira_issue_selector/index.tswebapp/src/components/jira_issue_selector/jira_issue_selector.tsxwebapp/src/components/modals/full_screen_modal/full_screen_modal.tsxwebapp/src/components/setting.tsxwebapp/src/components/setup_ui/index.tswebapp/src/components/setup_ui/setup_ui.tsxwebapp/src/utils/posts.tswebapp/src/utils/user_agent.ts
|
|
||
| import React from 'react'; | ||
| import PropTypes from 'prop-types'; | ||
| import type {Theme} from 'mattermost-redux/types/preferences'; |
There was a problem hiding this comment.
The Theme type lives in mattermost-redux/selectors/entities/preferences, which is what every other file in this webapp uses. The build passes only because import type is erased before webpack runs.
import type {Theme} from 'mattermost-redux/selectors/entities/preferences';
|
|
||
| import React, {Component} from 'react'; | ||
| import PropTypes from 'prop-types'; | ||
| import type {Theme} from 'mattermost-redux/types/preferences'; |
There was a problem hiding this comment.
Same as in jira_field.tsx
| theme: PropTypes.object.isRequired, | ||
| addValidate: PropTypes.func.isRequired, | ||
| removeValidate: PropTypes.func.isRequired, | ||
| type JiraFieldData = { |
There was a problem hiding this comment.
JiraField, IssueMetadata, etc. are already exported from types/model. The local Field, FieldSchema, AllowedValue types are structurally narrower than the model's JiraField, which is why isTeamField(field) would fail typechecking, isTeamField is typed against JiraField | FilterField not this local shape. Use the canonical model types so the rest of the codebase stays consistent.
| @@ -111,7 +150,7 @@ export default class JiraField extends React.Component { | |||
| <JiraEpicSelector | |||
There was a problem hiding this comment.
on line 93 style.getStyle() only returns { jiraIcon: {...} } so selectComponent is undefined and this is a style={undefined} no-op. The original .jsx had the same bug but it was hidden because JSX didn't typecheck. Either restore the missing entry or drop the style prop.
|
This PR has been automatically labelled "stale" because it hasn't had recent activity. |
…rics - input.tsx: Replace parseInt() with Number() to preserve decimal values and correctly handle 0 as a valid number input. Fix isValid() to not reject 0 — now checks for undefined/null/'' explicitly. Use nullish coalescing (??) instead of || for value rendering to keep 0 visible. - jira_field.tsx: Import Theme from mattermost-redux/selectors/entities/ preferences (canonical path) instead of mattermost-redux/types/ preferences. Replace local Field/FieldSchema/AllowedValue type defs with canonical JiraField, AllowedValue from types/model. Make Props match the actual caller (projectKey?: string, issueMetadata: IssueMetadata | null). Remove dead selectComponent style prop from IconOption (getStyle() never returned it). - jira_issue_selector.tsx: Same Theme import fix.
|
Review feedback addressed in commit ce2932c: input.tsx
jira_field.tsx
jira_issue_selector.tsx
|
|
Hi @nang2049, I've addressed all review feedback in commit ce2932c:
@coderabbitai could you re-review? |
🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
gh pr diff 1316 --repo mattermost/mattermost-plugin-jira > /tmp/pr.diff
wc -l /tmp/pr.diff
grep -n "parseInt\|Number(\|isValid\|selectComponent\|Theme\|preferences\|FieldSchema\|AllowedValue\|projectKey\|issueMetadata" /tmp/pr.diff | head -100Length of output: 1694 🏁 Script executed: #!/bin/bash
sed -n '1,220p' /tmp/pr.diffLength of output: 7908 All the claimed fixes check out against the diff for commit ce2932c:
Everything matches the description — these look like solid fixes that improve type accuracy and correctness (especially the ✏️ Learnings added
✅ Action performedReview finished.
|
3 participants
Summary
Converts all remaining
.jsand.jsxfiles to TypeScript (.ts/..tsx`), following the pattern from PR #1140.Files Converted (11 total)
Utils:
utils/posts.jsx->posts.tsutils/user_agent.jsx->user_agent.tsComponents:
components/setting.jsx->setting.tsxcomponents/form_button.jsx->form_button.tsxcomponents/input.jsx->input.tsxcomponents/jira_field.jsx->jira_field.tsxcomponents/setup_ui/setup_ui.jsx->setup_ui.tsxcomponents/setup_ui/index.js->index.tscomponents/jira_issue_selector/jira_issue_selector.jsx->jira_issue_selector.tsxcomponents/jira_issue_selector/index.js->index.tscomponents/modals/full_screen_modal/full_screen_modal.jsx->full_screen_modal.tsxChanges
PropTypeswith proper TypeScripttype/interfacedefinitionsChangeEvent,KeyboardEvent).jsxextensionsdisabledprop on AsyncSelect changed toisDisabled(react-select v3 API)Ticket Link
Fixes #1142
Checklist
te char/e2etests not affected (no logic changes)/release-noteChange Impact: 🟡 Medium
Reasoning: This PR converts 11 files from JavaScript/PropTypes to TypeScript across components and utilities. While most changes are typing-only migrations following an established pattern (PR
#1140), there are some behavioral modifications (AsyncSelectdisabled→isDisabledAPI update, Input component validation state clearing, numeric input handling) that introduce regression risk across multiple component implementations.Regression Risk: Moderate. The PR maintains intended behavior per the description, but affects multiple component files (FormButton, Input, JiraField, JiraIssueSelector, FullScreenModal, Setting, SetupUI) with behavioral refinements beyond pure typing. The AsyncSelect API change and Input component's modified
componentDidUpdatehook clearing invalid state when props change could have unexpected interactions in parent components if not thoroughly tested. Utilities (posts.ts, user_agent.ts) are low-risk but shared. Existing e2e/char tests are expected to remain unaffected, but edge cases in numeric input handling and validation state management warrant attention.QA Recommendation: Manual QA is recommended with medium-to-high priority. Test focus should include: (1) AsyncSelect components with dynamic enable/disable scenarios in Jira-related flows; (2) numeric input edge cases and validation state transitions; (3) FullScreenModal keyboard event handling; (4) Jira field selection workflows. Automated test coverage appears adequate (PR notes existing tests remain unaffected), but behavioral modifications and integration points between modified components and parent consumers should be validated in staging/development environments.
Generated by CodeRabbitAI