Skip to main content

App Frontend

The frontend is a React app under app-frontend/ (and optionally app-install-frontend/ for install-only UI). You own screens, state, and calls into the backend; the Appnest custom stack handles bundling, base paths, and loading your root component.


Entry point

  • The framework loads your UI from the React tree rooted at app-frontend/src/App.jsx (or the path your template uses—App.jsx is the usual root). Build features there or in components it imports.

Calling the backend from the UI

Depending on your app template, you may use one of these patterns:

  1. appBackendInvoke({ apiFunctionName, payload, options? }) from the client SDK—see Frontend Functions (returns the parsed JSON body of the response in our documented helper shape).
  2. window.appnestClientFunctions.appBackend.invoke({ apiFunctionName, payload }) when your scaffold exposes the global client—often returns { statusCode, body }: statusCode is HTTP-style (200, 400, 401, …); body is the backend return value. If the backend uses ResultData({ body, statusCode }), those values are reflected; otherwise the framework may default statusCode (e.g. 200) and expose a plain return as body.

Prefer the API your generated app already uses; align with App Backend for what each function returns.

Behind the local dev proxy, relative /app-backend/... fetches may also be used for some setups—see your template and App Overview.


UI stack: Twigs

Use Twigs—SurveySparrow’s themeable React component library—for UI:

  • @sparrowengg/twigs-react — components
  • @sparrowengg/twigs-react-icons — icons

Add both to app-frontend/package.json. Prefer version "*" (latest) unless your team pins a known-good release—avoid pinning to ranges that do not exist on the registry.

Rules of thumb

  • Use Twigs for controls and patterns the library provides—avoid raw HTML widgets such as <button>, <input>, <select>, <table> when Twigs has an equivalent.
  • Use Stack and Box (or Twigs layout primitives) for layout; avoid one-off CSS where tokens and props suffice.
  • Prefer Twigs design tokens over hardcoded colors (hex).
  • Do not recreate .btn / .alert-style ad hoc classes when Twigs already exposes those patterns.

Look and feel

Apps run inside the host SaaS product. Aim for a polished experience: clear navigation, readable type, consistent spacing, predictable interactions. Use responsive patterns (Twigs responsive props) so layouts work on desktop, tablet, and mobile and feel native to the host.


Build output

After production build, expect output under app-frontend/dist (or whatever your template configures) for validate and pack.

ESLint during validate may treat PascalCase imports as JSX components to reduce false “unused” warnings.


Unused catch

If you do not use the error, use a parameterless catch { } (not an unused catch (e)).


Further reading (this site)

TopicDocument
App shape & foldersApp Overview
Backend exports & return shapesApp Backend
appBackendInvoke (SDK-style)Frontend Functions
Manifest (frontend_locations, …)Manifest
Where UI surfaces appear in the productProduct Location
Twigs (components, docs, examples)twigs.surveysparrow.com