Rating UI React

A simple rating component that demonstrates essential React concepts and patterns. This project showcases how fundamental React features work together to build interactive user interfaces.

Live demo: https://felipeozalmeida.github.io/rating-ui-react/

What You'll Find Here

This rating UI implementation covers these key React concepts:

1. JSX - Writing component markup
2. Components - Building reusable UI pieces
3. Styling - Applying global, scoped, and dynamic styles
4. Props & State - Managing data flow and component state
5. Events - Handling user interactions
6. Lists - Rendering dynamic collections
7. Conditional Rendering - Showing/hiding UI based on conditions
8. Children Components - Component composition patterns
9. Effects - Managing side effects and lifecycle
10. Portals - Rendering outside the component tree (e.g. modals)
11. Accessibility (a11y) - Keyboard navigation, focus management, ARIA roles, and feedback

Getting Started

First, make sure you have a suitable Node.js version installed. For reference, this project was developed with:

1. node v24.18.0
2. npm v11.16.0

Install dependencies with your favorite package manager. Assuming it's npm:

npm install

Then you're ready to go with:

npm run dev

Running Tests

Every spec names the environment it runs in with a qualifier in its filename, such as Rating.dom.spec.tsx. The environments are ordered by fidelity, from the cheapest to the most faithful:

qualifier	runs in
.node.	Node, with no DOM (.ts only)
.dom.	the default DOM implementation, currently happy-dom
.happy-dom.	happy-dom
.jsdom.	jsdom
.browser.	real Chromium through Playwright, with layout and CSS

Pick the cheapest one that can see what the spec tests:

• .node. for logic that doesn't touch the DOM
• .dom. for rendering, props, state, events and ARIA attributes, in components and hooks. Hooks need a DOM too, because rendering them goes through React DOM.
• .happy-dom. or .jsdom. only when the spec depends on that implementation
• .browser. for what the emulators can't see: layout and sizes, real CSS, including what it hides from view and from assistive technology, focus that depends on what's rendered, and workers

Some behaviour no environment here can see, such as what a screen reader announces. Check that by hand with one, such as VoiceOver or NVDA.

Watch every new spec fail before you make it pass, so you know it can fail. When you're unsure whether an emulator can see a bug, break the component on purpose, for example by hiding an element with CSS, and run the spec in both environments. If only .browser. turns red, the spec belongs there.

A spec without a qualifier fails lint.

Vitest, TypeScript and ESLint pick up both .spec. and .test. files. Wherever a config lists both, spec comes first, as in *.{spec,test}.{ts,tsx}.

Browser Mode specs run in Chromium through Playwright, which has to be downloaded once:

npm run test:install
npm run test:unit

On Linux, Chromium also needs some system libraries. On Debian, Ubuntu and their derivatives, Playwright can install them for you:

npm run test:install -- --with-deps

This uses apt, so it fails on other distributions. There, install Chromium's dependencies with your own package manager instead.