For the complete documentation index, see llms.txt. This page is also available as Markdown.

Naming Conventions: Crystal-Clear Boolean Values

←Back to Index

Core Principle: Components should just read clear boolean values from context, not calculate them. No confusing conditionals scattered across components.

Good vs Bad Naming

Bad (unclear):

const restricted = work.access?.restrictedAccessStatus;
const digital = work.production?.some(p => p.type === 'BornDigital');
const imgs = canvases.every(c => c.type === 'Image');

Good (crystal clear):

const { 
  isCurrentCanvasRestricted,
  isWorkBornDigital,
  hasOnlyRenderableImages,
  hasMultipleCanvases,
  hasIiifImageService,
  hasDownloadableAssets,
  isFullscreenAvailable,
} = useItemViewerContextV2();

Boolean Naming Pattern

All boolean values follow this pattern:

  • is... - for state/status checks (isRestricted, isBornDigital, isFullscreen)

  • has... - for existence checks (hasImages, hasMultipleCanvases, hasDownloadOptions)

  • can... - for permission/ability checks (canDownload, canZoom, canShare)

  • should... - for conditional rendering (shouldShowThumbnails, shouldUseIiifLocation)

Comprehensive Derived Boolean Values

These should ALL be in ItemViewerContextV2, not calculated in components:

Benefits of Clear Naming

  1. Self-documenting code - isCurrentCanvasRestricted needs no comment

  2. Easier debugging - Immediately understand what condition is being checked

  3. Reduces errors - Less likely to misunderstand intent

  4. Better IDE support - Autocomplete shows exactly what's available

  5. Easier onboarding - New developers understand code faster

Component Usage Example

Before (confusing):

After (crystal clear):


Next: 04 - Test-First Approach

Last updated