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({ functionName, functionPayload, options? }) from the client SDK—see Frontend Functions (returns the parsed JSON body of the response in our documented helper shape).
  2. window.AppnestFunctions.$app.backend({ functionName, functionPayload }) 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