Skip to main content
Version: 1.1.0

Architecture

SpartanFX has one job that shapes its entire design: render the same components in four very different hosts — SPFx, PCF, Power Apps Code Apps, and standalone React. It achieves that with two patterns you'll see everywhere in the codebase and the docs: three entry points and the dual-export (UI + adapter) component.

Three entry points​

The package exposes three import paths, each a distinct public surface:

import { DataTable }               from '@spartanfx/react';          // host-agnostic UI
import { useSharePointDataTable }  from '@spartanfx/react/spfx';      // SharePoint adapters
import { useCASharePointDataTable } from '@spartanfx/react/codeapps'; // Code Apps adapters
Entry pointContainsPeer requirements
@spartanfx/reactAll standalone components, hooks, helpers. No host dependency.react, react-dom, @fluentui/react
@spartanfx/react/spfxSPFx-only components (ListForm, PeoplePicker, …) and the SharePoint adapter hooks for dual-purpose components.@pnp/sp, @pnp/graph, @microsoft/sp-webpart-base
@spartanfx/react/codeappsCode Apps adapter hooks plus shared service primitives, for pac code generated services.a generated <DataSource>Service you inject

The docs API Reference mirrors this exactly — one module per entry point (index, spfx, codeapps) — so "which page documents this?" always has the same answer as "which path do I import from?".

The dual-export component​

A data component such as DataTable, DocumentManager, Planner, TaskManager, or NotificationCenter is split into two halves:

  • A presentational component in the default entry point — pure UI, fully controlled, no knowledge of where data comes from.
  • One or more adapter hooks in /spfx and /codeapps — they fetch, page, and mutate data for a specific host, and return the props the component expects.
function ProjectFiles() {
  // adapter: host-specific data + handlers
  const table = useSharePointDataTable({ listTitle: 'Projects' });
  // component: host-agnostic UI
  return <DataTable {...table} />;
}

Swapping useSharePointDataTable for useCASharePointDataTable moves the same screen from SPFx to a Code App without touching the markup. This is why the component and its adapters are documented as separate symbols in separate modules.

Source layout​

The repository mirrors the public surface:

src/
  index.ts        → @spartanfx/react        (Components + Hooks + Helpers)
  spfx.ts         → @spartanfx/react/spfx    (Components/*/spfx + Helpers/spfx)
  codeapps.ts     → @spartanfx/react/codeapps (Components/*/codeapps + Common/codeapps)
  Components/<Name>/
    index.ts      ← standalone UI barrel
    spfx.ts       ← SharePoint adapter barrel
    codeapps.ts   ← Code Apps adapter barrel
    types/        ← props, tokens, class-name contracts

Each component folder keeps its UI and its adapters side by side but exported through different barrels — which is exactly how they reach you as three import paths.