Skip to content

Latest commit

 

History

History
45 lines (32 loc) · 2.24 KB

File metadata and controls

45 lines (32 loc) · 2.24 KB

react-ts-patterns

A todo app implementation in React 19 + TypeScript 7 intended to act as a playground for learning and demonstrating modern React, TS and UX best practices.

What is the purpose of this project?

The primary purpose to demonstrate to myself and others the latest React, TS and UX best practices for common use cases. A todo app was chosen because of it's simple, well understood domain that nevertheless creates the opportunity to implement loads of UI workflows.

By focusing on the latest solutions available in React, TS, HTML, CSS and the browser, my secondary goals is to update any old habits that would cause me to reach for previously recommended patterns (e.g. load data in a useEffect) when better patterns now exist for solving those problems (e.g. Suspense + use(promise) or a server component).

While this should ideally feel like the best todo app you've ever touched, it is not in fact a bona fide todo app; it's a React + TS + UX patterns workshop. UX here includes a11y, styling, animations, layout - everything that contributes to an intuitive journey for every user. This project's choices should demonstration how to achieve ideal UX outcomes via the best available React + TS patterns.

What to ask yourself as you work in this project?

  • How well does the project achieve the goals described above?
  • Could better UX patterns still be demonstrated?
  • Could better React or TS patterns still be demonstrated without compromising UX?
  • Could the patterns which have been demonstrated be expressed more clearly by refactoring the code or the file system?
  • Could the patterns be announced and explained more effectively in code comments or the README?

Assumptions to make

  • Proactive suggestions about better UX, React or TS patterns are always welcome
  • I may have outdated habits and am genuinely interested in updating my skills
  • UX always trumps React and TS; if showing off a particular pattern or achieving a cleaner code boundary would force a worse user experience, we do NOT want to do it; help ensure we don't

Things to check

  • Does the current change invalidate the README?
  • Does the current change add something the README doesn't mention but should?

Docs

(add a lookup table for what docs to read when)