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, 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({ apiFunctionName, 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)

Topic	Document
App shape & folders	App Overview
Backend exports & return shapes	App Backend
appBackendInvoke (SDK-style)	Frontend Functions
Manifest (frontend_locations, …)	Manifest
Where UI surfaces appear in the product	Product Location
Twigs (components, docs, examples)	twigs.surveysparrow.com