Fix: No Incidents Message #1763
Conversation
WalkthroughThis pull request introduces a new Changes
Sequence Diagram(s)sequenceDiagram
participant P as Parent Component
participant CB as ChartBox
participant EV as EmptyView
P->>CB: Render with isEmpty flag (true/false)
alt isEmpty true
CB->>EV: Render EmptyView with props (icon, header, noDataMessage)
EV-->>CB: Display empty state view
else isEmpty false
CB->>CB: Render chart content
end
Possibly related PRs
Suggested reviewers
✨ Finishing Touches
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? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
Client/src/Pages/Uptime/Details/Components/ChartBoxes/index.jsx (2)
100-102: Yo, this condition's got some repetition, dawg! Let's clean it up!Extract the reduce operation into a variable to avoid code duplication and improve readability.
+const totalDownChecks = monitor?.groupedDownChecks?.reduce( + (count, checkGroup) => count + checkGroup.totalChecks, + 0 +) ?? 0; + -{hoveredIncidentsData !== null || - (monitor?.groupedDownChecks?.reduce((count, checkGroup) => count + checkGroup.totalChecks, 0) > 0) ? ( +{hoveredIncidentsData !== null || totalDownChecks > 0 ? (
124-126: The message is straight fire, but let's make it translatable!Consider using a translation system for the "No incidents" message to support internationalization.
-Great. No incidents, yet! +{t('incidents.none')}
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
Client/src/Pages/Uptime/Details/Components/ChartBoxes/index.jsx(1 hunks)
🔇 Additional comments (1)
Client/src/Pages/Uptime/Details/Components/ChartBoxes/index.jsx (1)
100-128: This implementation is straight 🔥! Clean conditional rendering!The logic for handling both incident and no-incident scenarios is well-structured and matches the PR objectives perfectly. The conditional rendering provides a clear user experience.
![llamapreview[bot]](https://avatars.githubusercontent.com/in/1023541?s=60&v=4){kind=small}
There was a problem hiding this comment.
Auto Pull Request Review from LlamaPReview
1. Overview
1.1 PR Summary
- Business value and requirements alignment: The PR fixes an issue where no message was displayed when there were no incidents. It aligns with the business requirement of providing clear and concise information to users.
- Key components modified: The incident display logic in the UI.
- Impact assessment: The change will affect the user experience and visual representation of incidents.
- System dependencies and integration impacts: The change interacts with the incident data and the UI components responsible for displaying this data.
1.2 Architecture Changes
- System design modifications: None.
- Component interactions: The change interacts with the incident data and the UI components responsible for displaying this data.
- Integration points: None.
2. Detailed Technical Analysis
2.1 Code Logic Deep-Dive
Core Logic Changes
- Client/src/Pages/Uptime/Details/Components/ChartBoxes/index.jsx - ChartBoxes
- Submitted PR Code:
{hoveredIncidentsData !== null ||
(monitor?.groupedDownChecks?.reduce((count, checkGroup) => count + checkGroup.totalChecks, 0) > 0) ? (
// Original layout for when incidents exist
<Box position="relative">
<Typography component="span">
{hoveredIncidentsData !== null
? hoveredIncidentsData.totalChecks
: monitor?.groupedDownChecks?.reduce((count, checkGroup) => count + checkGroup.totalChecks, 0)}
</Typography>
{hoveredIncidentsData !== null && hoveredIncidentsData.time !== null && (
<Typography
component="h5"
position="absolute"
top="100%"
fontSize={11}
color={theme.palette.primary.contrastTextTertiary}
>
{formatDateWithTz(hoveredIncidentsData._id, dateFormat, uiTimezone)}
</Typography>
)}
</Box>
) : (
// Centered layout for "No incidents" message
<Box m="auto" marginY="25%">
<Typography component="span">
Great. No incidents, yet!
</Typography>
</Box>
)}- Analysis:
- The PR introduces conditional rendering based on the presence of incidents, which is a good approach for simplifying the UI and improving readability.
- However, the current logic assumes that
hoveredIncidentsDatais always available. If it'snulland there are no incidents, the component will throw an error when trying to accesshoveredIncidentsData.totalChecks. - The edge case where
hoveredIncidentsDataisnulland there are no incidents is not handled gracefully. - The
formatDateWithTzfunction is called even whenhoveredIncidentsData.timeisnull, which could lead to unexpected behavior or errors. - The "No incidents" message is hardcoded, which violates the "no hardcoded values" rule mentioned in the PR checklist.
- LlamaPReview Suggested Improvements:
{((hoveredIncidentsData?.totalChecks) !== undefined) ||
(monitor?.groupedDownChecks?.reduce((count, checkGroup) => count + checkGroup.totalChecks, 0) > 0) ? (
// Original layout for when incidents exist
<Box position="relative">
<Typography component="span">
{(hoveredIncidentsData?.totalChecks) ?? monitor?.groupedDownChecks?.reduce((count, checkGroup) => count + checkGroup.totalChecks, 0)}
</Typography>
{hoveredIncidentsData?.time !== null && (
<Typography
component="h5"
position="absolute"
top="100%"
fontSize={11}
color={theme.palette.primary.contrastTextTertiary}
>
{formatDateWithTz(hoveredIncidentsData._id, dateFormat, uiTimezone)}
</Typography>
)}
</Box>
) : (
// Centered layout for "No incidents" message
<Box m="auto" marginY="25%">
<Typography component="span">
{t('noIncidentsMessage')} {/* Use translation for the message */}
</Typography>
</Box>
)}- Improvement rationale:
- Using optional chaining (
?.) prevents the component from throwing an error when trying to access a property that isnullorundefined. - The
undefinedcheck ensures that the component does not throw an error whenhoveredIncidentsDataisnulland there are no incidents. - Using translations for the "No incidents" message ensures that the message is consistent across the application and can be easily updated if needed.
- The
formatDateWithTzfunction is only called whenhoveredIncidentsData.timeis notnull, preventing unexpected behavior or errors.
- Using optional chaining (
3. Critical Findings
Potential Issues
-
🔴 Critical Issues
- Issue: The current logic assumes that
hoveredIncidentsDatais always available, which can lead to errors if it'snulland there are no incidents. - Impact: The component will throw an error, leading to unexpected behavior and a poor user experience.
- Recommendation: Use optional chaining (
?.) and anundefinedcheck to prevent these errors.
- Issue: The current logic assumes that
-
🟡 Warnings
- Warning: The "No incidents" message is hardcoded, which violates the "no hardcoded values" rule mentioned in the PR checklist.
- Potential risks: Inconsistencies in the UI and difficulty maintaining the application.
- Suggested improvements: Use translations for the "No incidents" message to ensure consistency and ease of updates.
4. Security Assessment
Security Considerations
- Authentication/Authorization impacts: None.
- Data handling concerns: None.
- Input validation: The change does not introduce any new input validation concerns.
- Security best practices: The change aligns with security best practices.
- Potential security risks: None identified.
- Mitigation strategies: None required.
- Security testing requirements: None identified.
5. Testing Strategy
Testing Recommendations
-
Test Coverage:
- Unit test analysis: The change should be covered by unit tests to ensure that the conditional rendering logic works as expected.
- Integration test requirements: Integration tests should validate that the change works correctly with the rest of the application.
- Edge cases coverage: Tests should cover the edge case where
hoveredIncidentsDataisnulland there are no incidents.
-
Test Recommendations:
- Suggested Test Cases:
it('should display the "No incidents" message when there are no incidents', () => {
// Arrange
const monitor = { groupedDownChecks: [] };
const hoveredIncidentsData = null;
const { getByText } = render(<ChartBoxes monitor={monitor} hoveredIncidentsData={hoveredIncidentsData} />);
// Act & Assert
expect(getByText('Great. No incidents, yet!')).toBeInTheDocument();
});
it('should not throw an error when hoveredIncidentsData is null and there are no incidents', () => {
// Arrange
const monitor = { groupedDownChecks: [] };
const hoveredIncidentsData = null;
// Act & Assert
expect(() => render(<ChartBoxes monitor={monitor} hoveredIncidentsData={hoveredIncidentsData} />)).not.toThrow();
});- Coverage improvements: Ensure that the tests cover all possible scenarios, including edge cases.
- Performance testing needs: None identified.
6. Documentation & Maintenance
Documentation & Maintenance Considerations
- Documentation updates needed: The documentation should be updated to reflect the changes in the incident display logic.
- Long-term maintenance considerations: The change introduces a new layout for the "No incidents" scenario. It's important to ensure that this layout is maintained and updated as needed.
- Technical debt and monitoring requirements: None identified.
7. Deployment & Operations
Deployment & Operations Considerations
- Deployment impact and strategy: The change should be deployed as part of a regular release cycle.
- Key operational considerations: None identified.
8. Summary & Recommendations
8.1 Key Action Items
- Critical changes required: Implement the suggested improvements to prevent errors and ensure consistency in the UI.
- Important improvements suggested: Use translations for the "No incidents" message to ensure consistency and ease of updates.
- Best practices to implement: None identified.
- Cross-cutting concerns to address: None identified.
8.2 Future Considerations
- Technical evolution path: The change aligns with the technical evolution path of the application.
- Business capability evolution: The change aligns with the business capability evolution of the application.
- System integration impacts: The change does not introduce any new system integration impacts.
💡 Help Shape LlamaPReview
How's this review format working for you? Vote in our Github Discussion Polls to help us improve your review experience!
|
Can you please our one of standard fonts / colors from the theme? The font size / color of 'Incidents' header is a good fit for that. |
Have made the changes. |
There was a problem hiding this comment.
This PR is a bit too myopic in nature, it only works for this one component. What happens when another ChartBox needs an empty view? We have to search through the codebase to find this specific implementation and copy it in order to be consistent. This is not maintainable.
A more comprehensive and maintainable approach would be to implement an empty view for the ChartBox component. We would then have the same empty view for all components that use ChartBox.
Another note I am trying to remove all ternary and most inline conditional rendering from this project, so please avoid unless absolutely necessary, use early returns instead, it keeps the code much cleaner and readable.
Alright, I understood your vision. We can create an empty view that takes in some kind of text as what to appear when we have an empty chartbox. Am I going in the right direction? Additionally, for the ternary operation, yes I can remove the use of it altogether, I was not aware that you are thinking of removing them and hence thought that this can be used |
Yes, I think the approach you outlined is reasonable. ChartBox can take a String to display as an empty view, with a default value of "No data" or something like that.
Yes, I am trying to remove as much complexity as I can from the application. Please follow the principle of early return as much as possible rather than conditionally rendering things. In pseudo code: instead of If |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
Client/src/Pages/Uptime/Details/Components/ChartBoxes/EmptyView.jsx (2)
5-13: Yo, let's make this component more theme-consistent and responsive!The component looks solid, but we could improve it by:
- Using theme spacing for margins
- Using theme typography variants for consistent styling
Here's a more theme-consistent version:
-const EmptyView = ({ message = "No Data", size = "h2" }) => { +const EmptyView = ({ message = "No Data", size = "h2", spacing = 8 }) => { return ( - <Box m="auto" marginY="25%"> + <Box + m="auto" + marginY={(theme) => theme.spacing(spacing)} + textAlign="center" + > <Typography variant={size}> {message} </Typography> </Box> ); };
15-20: Yo, let's beef up these PropTypes!The PropTypes are good but could be more robust:
- Make message required since it's a core prop
- Add PropTypes for the spacing prop
EmptyView.propTypes = { - message: PropTypes.string, + message: PropTypes.string.isRequired, size: PropTypes.oneOf(['h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'body1', 'body2']), + spacing: PropTypes.number };Client/src/Pages/Uptime/Details/Components/ChartBoxes/index.jsx (2)
40-81: Yo, this function's got a lot on its plate!The renderUptime function could use some cleanup:
- Extract the hover timestamp display into a separate component
- Use theme typography variants instead of hard-coded font sizes
- fontSize={11} + variant="caption"Also, consider extracting the timestamp display:
const TimeStamp = ({ time, dateFormat, uiTimezone }) => ( <Typography component="h5" position="absolute" top="100%" variant="caption" color={(theme) => theme.palette.primary.contrastTextTertiary} > {formatDateWithTz(time, dateFormat, uiTimezone)} </Typography> );
165-175: Yo, let's make these PropTypes more specific!The PropTypes could be more detailed, especially for complex objects:
- monitor: PropTypes.object, + monitor: PropTypes.shape({ + upChecks: PropTypes.shape({ + totalChecks: PropTypes.number + }), + downChecks: PropTypes.shape({ + totalChecks: PropTypes.number + }), + avgResponseTime: PropTypes.number, + groupedUpChecks: PropTypes.arrayOf(PropTypes.shape({ + totalChecks: PropTypes.number, + _id: PropTypes.string + })), + groupedDownChecks: PropTypes.arrayOf(PropTypes.shape({ + totalChecks: PropTypes.number, + _id: PropTypes.string + })) + }),
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
Client/src/Pages/Uptime/Details/Components/ChartBoxes/EmptyView.jsx(1 hunks)Client/src/Pages/Uptime/Details/Components/ChartBoxes/index.jsx(5 hunks)
🔇 Additional comments (2)
Client/src/Pages/Uptime/Details/Components/ChartBoxes/EmptyView.jsx (1)
1-4: Yo, these imports are clean and organized!The separation between component imports and utility imports is on point.
Client/src/Pages/Uptime/Details/Components/ChartBoxes/index.jsx (1)
110-115: Yo, this function's clean and lean!The renderResponseTime function is well-structured with a good early return pattern.
| const renderIncidents = () => { | ||
| const downChecks = monitor?.groupedDownChecks?.reduce((count, checkGroup) => count + checkGroup.totalChecks, 0); | ||
| if (!downChecks && !hoveredIncidentsData) { | ||
| return <EmptyView message="Great. No incidents, yet!" />; | ||
| } | ||
| return ( | ||
| <Box position="relative"> | ||
| <Typography component="span"> | ||
| {hoveredIncidentsData !== null | ||
| ? hoveredIncidentsData.totalChecks | ||
| : downChecks} | ||
| </Typography> | ||
| {hoveredIncidentsData !== null && hoveredIncidentsData.time !== null && ( | ||
| <Typography | ||
| component="h5" | ||
| position="absolute" | ||
| top="100%" | ||
| fontSize={11} | ||
| color={theme.palette.primary.contrastTextTertiary} | ||
| > | ||
| {formatDateWithTz(hoveredIncidentsData._id, dateFormat, uiTimezone)} | ||
| </Typography> | ||
| )} | ||
| </Box> | ||
| ); | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Yo, we're seeing some code déjà vu here!
The renderIncidents function duplicates logic from renderUptime:
- TimeStamp display logic is repeated
- Hard-coded font size appears again
Extract shared components and use theme values:
- fontSize={11}
+ variant="caption"Consider creating a shared utility for check counting:
const getTotalChecks = (checks) =>
checks?.reduce((count, checkGroup) =>
count + checkGroup.totalChecks, 0) ?? 0;
WhatsApp.Video.2025-02-15.at.16.51.00.mp4I have refactored Chartboxes and made early return statements. |
Br0wnHammer
force-pushed
the
fix/fe/incidents-text
branch
from
002d0cc to
a6bb756
Compare
Br0wnHammer
force-pushed
the
fix/fe/incidents-text
branch
from
a6bb756 to
2879126
Compare
|
Hey @ajhollid , I have made use of low level empty view component. Similarly for incidents: 
|
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
src/Components/Charts/ChartBox/index.jsx (1)
7-18: 🛠️ Refactor suggestionYo dawg, let's complete those PropTypes!
I noticed some props being used but not validated. Let's fix that to keep our code tight!
Add these missing PropTypes:
ChartBox.propTypes = { children: PropTypes.node, icon: PropTypes.node, header: PropTypes.string, height: PropTypes.string, noDataMessage: PropTypes.string, - isEmpty: PropTypes.bool + isEmpty: PropTypes.bool, + justifyContent: PropTypes.string, + Legend: PropTypes.node, + borderRadiusRight: PropTypes.number, + sx: PropTypes.object };🧰 Tools
🪛 ESLint
[error] 12-12: 'justifyContent' is missing in props validation
(react/prop-types)
[error] 13-13: 'Legend' is missing in props validation
(react/prop-types)
[error] 14-14: 'borderRadiusRight' is missing in props validation
(react/prop-types)
[error] 15-15: 'sx' is missing in props validation
(react/prop-types)
[error] 15-15: 'sx' is defined but never used.
(no-unused-vars)
🧹 Nitpick comments (1)
src/Components/Charts/ChartBox/EmptyView.jsx (1)
7-15: Lose yourself in the optimization! 🎤Consider memoizing this component to prevent unnecessary re-renders when parent updates.
+import { memo } from 'react'; const EmptyView = ({ icon, header, message = "No Data", size = "h2", borderRadiusRight = 4, justifyContent = "flex-start", height = "300px" -}) => { +}) => memo(() => { const theme = useTheme(); // ... rest of the component -}; +});🧰 Tools
🪛 ESLint
[error] 12-12: 'borderRadiusRight' is missing in props validation
(react/prop-types)
[error] 13-13: 'justifyContent' is missing in props validation
(react/prop-types)
[error] 14-14: 'height' is missing in props validation
(react/prop-types)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/Components/Charts/ChartBox/EmptyView.jsx(1 hunks)src/Components/Charts/ChartBox/index.jsx(3 hunks)
🧰 Additional context used
🪛 ESLint
src/Components/Charts/ChartBox/EmptyView.jsx
[error] 12-12: 'borderRadiusRight' is missing in props validation
(react/prop-types)
[error] 13-13: 'justifyContent' is missing in props validation
(react/prop-types)
[error] 14-14: 'height' is missing in props validation
(react/prop-types)
🔇 Additional comments (2)
src/Components/Charts/ChartBox/index.jsx (1)
20-22: Straight fire! Early return pattern looking clean! 🔥The early return pattern for empty state is well implemented. It improves code readability and reduces nesting.
src/Components/Charts/ChartBox/EmptyView.jsx (1)
66-68: Typography component looking clean! 💯Good use of dynamic size prop with Typography component. The flexibility will help maintain consistent styling across different use cases.
| EmptyView.propTypes = { | ||
| message: PropTypes.string, | ||
| icon: PropTypes.node, | ||
| header: PropTypes.string, | ||
| size: PropTypes.oneOf(['h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'body1', 'body2']) | ||
| }; |
There was a problem hiding this comment.
Mom's spaghetti time! Let's fix those PropTypes! 🍝
Static analysis caught some missing PropTypes. Let's add them to keep our code robust!
EmptyView.propTypes = {
message: PropTypes.string,
icon: PropTypes.node,
header: PropTypes.string,
- size: PropTypes.oneOf(['h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'body1', 'body2'])
+ size: PropTypes.oneOf(['h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'body1', 'body2']),
+ borderRadiusRight: PropTypes.number,
+ justifyContent: PropTypes.string,
+ height: PropTypes.string
};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| EmptyView.propTypes = { | |
| message: PropTypes.string, | |
| icon: PropTypes.node, | |
| header: PropTypes.string, | |
| size: PropTypes.oneOf(['h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'body1', 'body2']) | |
| }; | |
| EmptyView.propTypes = { | |
| message: PropTypes.string, | |
| icon: PropTypes.node, | |
| header: PropTypes.string, | |
| size: PropTypes.oneOf(['h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'body1', 'body2']), | |
| borderRadiusRight: PropTypes.number, | |
| justifyContent: PropTypes.string, | |
| height: PropTypes.string | |
| }; |
| size = "h2", | ||
| borderRadiusRight = 4, | ||
| justifyContent = "flex-start", | ||
| height = "300px" |
There was a problem hiding this comment.
No hardcoded values please, especially non relative dimensions
| icon, | ||
| header, | ||
| message = "No Data", | ||
| size = "h2", |
There was a problem hiding this comment.
h2 is not a size, this prop is misleading.
h2 is a heading level
| header, | ||
| message = "No Data", | ||
| size = "h2", | ||
| borderRadiusRight = 4, |
There was a problem hiding this comment.
Do we need border radius as a prop? This seems excessive for configuration
| border: 1, | ||
| borderStyle: "solid", | ||
| borderColor: theme.palette.primary.lowContrast, | ||
| borderRadius: 2, |
There was a problem hiding this comment.
Most borders in the application are radius of 4, any reason for 2 here?
There was a problem hiding this comment.
I was following the styling defined in chartbox low level component.
There was a problem hiding this comment.
Using borderRadius as 4 makes the UI inconsistent for chartboxes.
BorderRadius: 2 is implemented similar to ChartBox Component.
| "& h2": { | ||
| color: theme.palette.primary.contrastTextSecondary, | ||
| fontSize: 15, | ||
| fontWeight: 500, |
There was a problem hiding this comment.
Please do not override heading font sizes or weights
| height, | ||
| minWidth: 250, | ||
| "& h2": { | ||
| color: theme.palette.primary.contrastTextSecondary, |
There was a problem hiding this comment.
Please don't override heading text colors
There was a problem hiding this comment.
The heading and text theme styles were overridden to match the chart box component similar to how they were implemented in that component., ensuring a consistent UI flow. Without this override, the Empty View would appear inconsistent.
| }, | ||
|
|
||
| "& tspan, & text": { | ||
| fill: theme.palette.primary.contrastTextTertiary, |
There was a problem hiding this comment.
The theme styles fonts and they should not be overridden unless there is a very good reason
| message: PropTypes.string, | ||
| icon: PropTypes.node, | ||
| header: PropTypes.string, | ||
| size: PropTypes.oneOf(['h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'body1', 'body2']) |
There was a problem hiding this comment.
I don't believe we provide styling for anything beyond h3, please remove anything beyond h3
| }} | ||
| > | ||
| <Stack | ||
| alignSelf="flex-start" |
There was a problem hiding this comment.
Is there a reason for alignSelf in a child of a flex box component?
You should be able to align this component using the parent flex component.
There was a problem hiding this comment.
in this specific case, using alignSelf: "flex-start" is intentional and necessary to achieve the desired layout similar to how it was implement in chartbox component.
The goal is to align the header and icon to the start of the flex container while keeping the rest of the content centered.
Without the alignSelf property. The UI looks as such.
| @@ -95,6 +96,8 @@ const ChartBoxes = ({ | |||
| <ChartBox | |||
| icon={<IncidentsIcon />} | |||
| header="Incidents" | |||
| noDataMessage="Great. No Incidents, yet!" | |||
| isEmpty={!monitor?.groupedDownChecks?.length} | |||
There was a problem hiding this comment.
Please avoid truthy falsey comparisons, use strict evaluations so it's clear what you are trying to do
Describe your changes
This update modifies the incident display logic in the UI. It now conditionally renders the following:
[Have tested on Safari, Chrome & Firefox]
Issue number
#1757
Please ensure all items are checked off before requesting a review. "Checked off" means you need to add an "x" character between brackets so they turn into checkmarks.