Skip to main content

frontend-patterns

Apply EduHub frontend conventions for components, layout, translations, TableGrid usage, and responsive behavior. Use when creating or refactoring frontend components or pages in the Next.js app.

Datos de origen

Repositorio
eduhub-org/eduhub
Última actividad en el origen
18 de septiembre de 2026 a las 11:17
Idioma detectado de SKILL.md
inglés
Estrellas
14
Forks
9

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Explorador de archivos
3 archivos

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
frontend-patterns
description
Apply EduHub frontend conventions for components, layout, translations, TableGrid usage, and responsive behavior. Use when creating or refactoring frontend components or pages in the Next.js app.
# Frontend Patterns Use this skill for frontend component and page work in `frontend-nx/apps/edu-hub` and `frontend-nx/apps/stujo`. ## Core Rules - organize code by feature, not by generic technology buckets - check existing shared components before creating a new one - build StuJo screens from the edu-hub components; never fork one to restyle it - prefer composition and small focused hooks over large monolithic components - keep user-facing text in translations, not inline strings - make layouts and interactions work on mobile as well as desktop ## Reuse First Before creating new UI, check: - `components/common/` - `components/common/dialogs/` - `components/inputs/` - `components/common/TableGrid/` Common existing building blocks include: - `ErrorMessageDialog` - `QuestionConfirmationDialog` - `NotificationSnackbar` - `CreatableTagSelector` - `DropDownSelector` - `InputField` - `TableGrid` ## Two Apps, One Component Set `frontend-nx/apps/stujo` (the StuJo job board) is not a separate design system. The apps must differ in design tokens, not in forked components, and the amount they share is meant to grow. - Import shared code through the `@eduhub/*` alias in `tsconfig.base.json`; `apps/stujo/next.config.js` enables `experimental.externalDir` for it. - To restyle a shared component for StuJo, override the `--eduhub-*` CSS variables in `apps/stujo/styles/globals.css`. Every colour in `apps/edu-hub/tailwind.config.js` resolves to one of those variables, so a token change is the whole job. Copying the component instead is the thing this rule exists to prevent. - Both apps use `apps/edu-hub/tailwind.config.js`. StuJo's config extends it and its `content` globs must include `../edu-hub/components/**`, or Tailwind emits no classes for a shared component and it renders unstyled. - Tailwind preflight is off in StuJo: the app is a CSS port of the Rails site that relies on browser defaults. Turning it on is its own change. - A component calling `useTranslations('common')` needs its keys in **both** `apps/edu-hub/locales/*.json` and `apps/stujo/locales/*.json` — separate namespaces. - `variant` on `DropDownSelector` / `InputField` selects a style family, not an app: with shared tokens, `'eduhub'` is the right variant inside StuJo too. - StuJo keeps its own ported layer (`--stujo-*` variables, `stujo-*` classes) for page chrome. That stays, and is not a reason to fork a shared component. Background: `docs/STUJO_INTEGRATION_PLAN.md` §8.1, `AGENTS.md` rule 10. ## Component Structure - keep feature code near the feature it serves - extract complex logic into a custom hook when the component becomes hard to read - avoid deep component nesting and broad prop drilling - use TypeScript interfaces for props ## Translations German must use the informal "Du" form. Keep translations in `frontend-nx/apps/edu-hub/locales/` and add new keys to both: - `de.json` - `en.json` Read `references/translations.md` for naming and enum-key rules. ## TableGrid Use the shared `TableGrid` rather than reinventing table behavior. Read `references/tablegrid.md` when: - adding a new table - configuring columns - wiring search or pagination - deciding between table and mobile-card presentation ## Responsive Behavior - start from the smallest useful layout first - ensure tap targets and action visibility remain usable on mobile - when dense tables become unreadable on mobile, consider a card-like representation instead of forcing every desktop column into view ## Output Style For This Skill When making frontend changes, mention the existing components or patterns you reused before creating anything new.
Ver en GitHub