docs(website): display count on error tab in playground

[developer-bandi]

PR Checklist

• Addresses an existing open issue: fixes Enhancement: Display error count on tabs in playground #8641
• That issue was marked as accepting prs
• Steps in Contributing were taken

Overview

As if raising an issue, make error count view in playground

In my opinion, there is no great meaning in indicating all the number of errors, and it is not neatly displayed in the UI, so errors with more than 9 are indicated as 9+.

[typescript-eslint]

Thanks for the PR, @developer-bandi!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

---

🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint.

[netlify]

✅ Deploy Preview for typescript-eslint ready!

Name	Link
🔨 Latest commit	5e12d16
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/662df2bd32de34000893b859
😎 Deploy Preview	https://deploy-preview-8643--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 96 (🟢 up 3 from production) Accessibility: 100 (no change from production) Best Practices: 92 (no change from production) SEO: 98 (no change from production) PWA: 80 (no change from production) View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 5e12d16. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

---

✅ Successfully ran 31 targets

• nx test typescript-eslint --coverage=false
• nx run types:build
• nx test visitor-keys --coverage=false
• nx test type-utils --coverage=false
• nx test scope-manager --coverage=false
• nx run repo-tools:postinstall-script
• nx test utils --coverage=false
• nx test typescript-estree --coverage=false
• nx test repo-tools --coverage=false
• nx run-many --target=build --parallel --exclude=website --exclude=website-eslint
• nx test eslint-plugin --coverage=false
• nx test ast-spec --coverage=false
• nx test rule-schema-to-typescript-types --coverage=false
• nx test parser --coverage=false
• nx test eslint-plugin-internal --coverage=false
• nx run-many --target=lint --parallel --exclude eslint-plugin
• nx test utils
• nx test visitor-keys
• nx test parser
• nx test type-utils
• nx test typescript-estree
• nx test eslint-plugin-internal
• nx test typescript-eslint
• nx test scope-manager
• nx test eslint-plugin
• nx test repo-tools
• nx test rule-schema-to-typescript-types
• nx test ast-spec
• nx run-many --target=typecheck --parallel
• nx run integration-tests:test
• nx run repo-tools:generate-configs

---

Sent with 💌 from NxCloud.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.38%. Comparing base (01cbca5) to head (b33fcc2).
Report is 149 commits behind head on main.

❗ Current head b33fcc2 differs from pull request most recent head 5e12d16. Consider uploading reports for the commit 5e12d16 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8643      +/-   ##
==========================================
+ Coverage   87.21%   87.38%   +0.17%     
==========================================
  Files         251      254       +3     
  Lines       12305    12489     +184     
  Branches     3880     3919      +39     
==========================================
+ Hits        10732    10914     +182     
- Misses       1303     1304       +1     
- Partials      270      271       +1     

Flag	Coverage Δ
unittest	87.38% <ø> (+0.17%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

see 27 files with indirect coverage changes

[yeonjuan]

Hi @developer-bandi, Looks like a good start! I haven't dug deep into the website code, so I'm commenting based on the behavior shown in the preview.

This way, even if we don't select the tab, we can aware that errors occurred.

As written in the issue, the intent of this enhancement was to recognize that an error occurred on a particular tab even when it was not selected.
However, with the current implementation, it seems that only the selected tab exposes the error count. I think the error count should be exposed even when the tab is not selected.

2024-03-12.2.05.15.mov

[developer-bandi]

Hi @developer-bandi, Looks like a good start! I haven't dug deep into the website code, so I'm commenting based on the behavior shown in the preview.

This way, even if we don't select the tab, we can aware that errors occurred.

As written in the issue, the intent of this enhancement was to recognize that an error occurred on a particular tab even when it was not selected. However, with the current implementation, it seems that only the selected tab exposes the error count. I think the error count should be exposed even when the tab is not selected.

2024-03-12.2.05.15.mov

thank you for review!. I understand the intend of the issue. and i suggest the addtional ui to resolve that request.

The UI that shows error count is maintained, and when an error occurs, a warning icon is displayed next to the code, eslintrc, and tsconfig tabs. If you look at the image, it looks like this:

this method seems clearer than exposing the number of errors when you click on another tab even if no error occurs. What do you think?

[developer-bandi]

I temporarily added code to reflect the previous comment. (There is an issue with the setMarkers type that could not be resolved, but it is not important for now.)

The current issue is that when entering the playground using a URL with a query containing code information, the warning display is only visible in the first code tab, and subsequent tabs must be activated to activate the warning display.

In order to accomplish this, the Monaco library needs a way to create markers in advance for the code, tsconfig, and eslintrc codes included in the query, but it is difficult to find a way because I am not familiar with the Monaco editor library. Could you please help me with this?

[developer-bandi]

add fix commit.

when go to playground with code, tsconfig, eslintrc code with query, error mark is evoke first time.

[armano2]

Hi @developer-bandi, Looks like a good start! I haven't dug deep into the website code, so I'm commenting based on the behavior shown in the preview.

This way, even if we don't select the tab, we can aware that errors occurred.

As written in the issue, the intent of this enhancement was to recognize that an error occurred on a particular tab even when it was not selected. However, with the current implementation, it seems that only the selected tab exposes the error count. I think the error count should be exposed even when the tab is not selected.

currently sadly there is no way to retrieve errors from other "files", they are not flushed when you change tab

---

In order to accomplish this, the Monaco library needs a way to create markers in advance for the code, tsconfig, and eslintrc codes included in the query, but it is difficult to find a way because I am not familiar with the Monaco editor library. Could you please help me with this?

sadly thats not really possible as is, as files are not mounted and validated, and they are created only when you actually set "model" as active.

typescript-eslint/packages/website/src/components/editor/LoadedEditor.tsx

Lines 58 to 76 in 4d6d0d5

	const tabsDefault = {
	// eslint-disable-next-line @typescript-eslint/no-non-null-assertion
	code: editor.getModel()!,
	tsconfig: monaco.editor.createModel(
	tsconfig,
	'json',
	monaco.Uri.file('/tsconfig.json'),
	),
	eslintrc: monaco.editor.createModel(
	eslintrc,
	'json',
	monaco.Uri.file('/.eslintrc'),
	),
	};
	tabsDefault.code.updateOptions({ tabSize: 2, insertSpaces: true });
	tabsDefault.eslintrc.updateOptions({ tabSize: 2, insertSpaces: true });
	tabsDefault.tsconfig.updateOptions({ tabSize: 2, insertSpaces: true });
	return tabsDefault;
	});

you can treat model as kind of file that can be loaded and unloaded from editor

---

word of caution, we are not using monaco that is installed in project, and we are using it only for types, and we are not always using same version as each version of typescript defines its own editor, remmember to check on different supported ts version :)

---

we should definitly define some state manager for errors, files and all other stuff as amount of properties that we are passing back and forward is slowly getting oo hand
this may be a little oo context of this change, but we should def do it soon

[developer-bandi]

@yeonjuan According to the answers above, it doesn't seem possible to expose an error when the tab is not selected.

Therefore, it seems better to close this mr or to expose the number of errors in the tab to the errros tab as was initially implemented. What do you think?

---

we should definitly define some state manager for errors, files and all other stuff as amount of properties that we are passing back and forward is slowly getting oo hand
this may be a little oo context of this change, but we should def do it soon

@armano2 I'm not sure if my understanding of the last sentence is correct.

From what I understand, the state in the playground below is not managed, so state management is being introduced using state management libraries such as zustand and redux or context API. Is this correct?

typescript-eslint/packages/website/src/components/Playground.tsx

Lines 27 to 46 in 4d6d0d5

	const windowSize = useWindowSize();
	const [state, setState] = useHashState(defaultConfig);
	const [astModel, setAstModel] = useState<UpdateModel>();
	const [markers, setMarkers] = useState<ErrorGroup[]>();
	const [ruleNames, setRuleNames] = useState<RuleDetails[]>([]);
	const [isLoading, setIsLoading] = useState<boolean>(true);
	const [tsVersions, setTSVersion] = useState<readonly string[]>([]);
	const [selectedRange, setSelectedRange] = useState<SelectedRange>();
	const [position, setPosition] = useState<number>();
	const [activeTab, setTab] = useState<TabType>('code');
	const [esQueryError, setEsQueryError] = useState<Error>();
	const [visualEslintRc, setVisualEslintRc] = useState(false);
	const [visualTSConfig, setVisualTSConfig] = useState(false);
	const playgroundMenuRef = useRef<ImperativePanelHandle>(null);
	const [optionsSize] = useState(() => {
	return Math.round(
	(parseFloat(getComputedStyle(document.documentElement).fontSize) * 2000) /
	window.innerWidth,
	);
	});

I understand that this work will not be carried out in this pr, but I am asking this question because I think it would be good to know properly!

[yeonjuan]

@developer-bandi

Therefore, it seems better to close this mr or to expose the number of errors in the tab to the errros tab as was initially implemented. What do you think?

IMO, It's good to just show the number of errors. But I'd love to hear from typescript-eslint members.

[JoshuaKGoldberg]

Yeah 👍 I'd rather get some improvement for now, even if it's not the ideal state. Either way we'll end up with followup issues filed for future refactors.

[developer-bandi]

Based on the summarized opinions, I have modified it so that only the number of errors occurring in the current tab can be checked.

[JoshuaKGoldberg]

Looks great to me, thanks! ✨

Just a small thing to touch up, nothing major on my end. Will re-request review from other Josh too.

[JoshuaKGoldberg]

Thanks! ✨